Upgrade/Queries Bugs

[bfarber]

We don't actually use this forum to gather a list of bugs, particularly as these "bugs" only affect developers (and sometimes they're not even bugs).

If you believe you've found a bug I would encourage you to submit a single ticket, per bug, with exact steps on how to reproduce the issue. If you have a (suggested) solution for the bug, feel free to include it.

[Midnight Modding]

I've looked and looked and can't find a way to add in custom code for the installer, similar to what I do in an upgrade.php file for another version. Looks like all first party apps have either nothing in setup/install or they have a queries.json file in it, but nothing similar to upgrade.php.

Looking through files, it appears to me there's no way to add in custom install stuff (outside of what can be done in queries.json)… I wanted to loop through all members and create them a row in my new table, which people suggested using. technically in this case, I don't "have" to do it, since it does a try/catch in a part of the app that will get those rows added when necessary, but at some point I will need to know.

newbie showed me a couple ways to do it (in Application.php or possibly in schema), but the problem then is there wouldn't be steps and there may be many member rows.

Also, is the following from dev docs, still accurate as of 4.3.6? In first party apps, I only see the new queries.json format, not any old queries.php files with the 3.x way of doing them.

Quote

If you are coming from an IP.Board 3 app, you can manually create a queries.php file in the applications/<your_app>/setup/<version>/ directory with the contents of the old mysql_updates.php file (setting an $SQL variable).

 

[bfarber]

No, there's nothing equivalent of upgrade.php for installing.

You could do what you're after with a single query, but that would be a long running query on bigger sites. The reality is - you shouldn't. There should absolutely be necessary need to copy every single member row to your own table. Just create them on the fly as needed.

And yes as I can recall we still support the old .php file defining the queries, even if we don't use it ourselves.

[Adriano Faria]

You can run scripts on installOther() in Applications.php. You won’t have steps but you can run queries. 

[Midnight Modding]

ok, thanks for the responses. yeah, I guess it's no big deal keeping the try/catch in to add them on the fly, and due to the setup of this app it really only "has" to have the try/catch a couple times because beyond this certain point every time the row is needed, it would for sure be there already. I would have just "rather" done it up front and I have it done in memberSynnc for new members, etc...

yeah, Adriano, I know about that (only because newbie just told me about it recently, otherwise I would have not noticed it), but the problem here is like Brandon was saying, for big sites it would be a potential problem doing it for all members at once.

Oh well. At least I am done with the app and was just mostly thinking ahead to public versions. I guess I'll just keep doing the adding on the fly, then.

[newbie LAC]

10 hours ago, Midnight Modding said:

for big sites it would be a potential problem doing it for all members at once.

Create Queue and run it from installOther()

[Midnight Modding]

1 hour ago, newbie LAC said:

Create Queue and run it from installOther()

yes, but then there's no guarantee it's done by the time the rows need to be there, so I'd still have to do the try/catch in some places, anyway, so I'm not sure if it's worth me doing or not.

For custom versions I could do that and instruct them to manually force the queued tasks to run until finished, but for a wide release, I'd have to fall back to using the try/catch, anyway.

[Midnight Modding]

Good thing I glanced back over my upgrade.php file. I did the time cutoff code like IPS, to avoid timeouts, and didn't notice that in one step I did bulk inserts "after" the foreach loop, so if it were ever to reach the cutoff limit before the loop ends, it wouldn't have inserted any of the rows considered "done", so had to add that bulk insert inside the cutoff check, as well!

Not that it's likely (I assume) at all for it to reach the cutoff limit on my step, though, but still better safe than sorry.