@diosmosis opened this Pull Request on January 23rd 2019 Member

Fixes #13992 (edit by @Findus23)

@fdellwing commented on January 23rd 2019 Contributor

Fixes #13992

@tsteur commented on January 25th 2019 Member

We could maybe move this one to 3.9? It be nice to have all SQL updates grouped, and all other commands in a separate box. So it is easier to copy/paste etc. Also in the list of commands we could then add a core:update? may not be needed though I suppose

@diosmosis commented on January 25th 2019 Member

It be nice to have all SQL updates grouped, and all other commands in a separate box. So it is easier to copy/paste etc.

Wouldn't this potentially cause problems related to order? Ie, one update activates plugin OurNewPlugin, next update assumes it's there and applies SQL on a table it assumes exists. If run separately, the SQL may not succeed.

@diosmosis commented on January 27th 2019 Member

Moving to 3.9.0.

@tsteur commented on January 28th 2019 Member

Wouldn't this potentially cause problems related to order? Ie, one update activates plugin OurNewPlugin, next update assumes it's there and applies SQL on a table it assumes exists. If run separately, the SQL may not succeed.

The MySQL queries would always need to be executed first for sure. Not sure if we had ever an issue where it doesn't work because of activating the plugins afterwards? Of course people might mess up and activate plugins first. But then they would either get an error when trying to update or so, or it would work a little bit later as soon as the DB queries are executed. Unless on update the plugins add more DB entries into a table assumed exists in which it can fail for sure.

None of the solutions seem 100% right so far

@diosmosis commented on January 28th 2019 Member

The MySQL queries would always need to be executed first for sure.

What I mean is there may be cases where an update assumes a plugin has been activated first, and executes SQL on tables that it assumes exists. Or that a plugin assumes a certain update has been applied and a table exists when installing/activating. In the first case, the plugin has to be activated first, in the second the SQL executed first. Migrations are meant to be run in order (as I'm sure you know), placing them out of order could create incorrect instructions.

@diosmosis commented on January 28th 2019 Member

We could also just show many code blocks, based on chunks of commands/sql. Eg:

Execute this sql...
...
Execute these commands...
...
Execute this sql...
...

etc. This way order would be preserved and we won't have users running the commands/sql improperly.

@tsteur commented on January 28th 2019 Member

Was thinking of the many boxes as well... especially since we don't often have plugin activates/deactivates this could be fine.

@diosmosis commented on February 9th 2019 Member

Here's what it looks like w/ multiple boxes:

image

@tsteur commented on February 10th 2019 Member

Looks awesome!

This Pull Request was closed on February 10th 2019
Powered by GitHub Issue Mirror