Hi,
I've decided to make this priority "critical", but downgrade if you disagree. I have two database users - one with MySQL "table alter" permissions and one without. I need to remember to switch my connection user to the correct one before running update.php but this is the restriction IT place on me, so that's the way it must be.
Today I was updating Imagefield and Imagecache, both of which had ALTER queries. I used the wrong user and got a FAILED messages at the end of the update run. No problem, I thought - I'll pick the correct user then run update again. But the second time update did nothing. I checked the system table and the schema_version
column has been updated to latest, even though the update actually failed to complete properly!
Surely this is wrong? =(
Comments
Comment #1
greg.harveyMoving to 7.x-dev for consideration there, as I guess this would need to trickle down. It is a valid issue still.
Comment #2
greg.harveyUm, *bump*
=)
Comment #3
moshe weitzman CreditAttribution: moshe weitzman commentedThis is the way it has always been. And I agree that it is wrong.
Note that in D7 yuo can't seemingly pick and choose which updates to run. You get all or none.
Comment #4
greg.harveyOh, man, that's no good. I guess Drush won't be able to support individual module updates either if core doesn't. The number of times I've had to run updates in a specific order because of some quirk of the installed modules or a because of a bug in a hook_update from a specific module. This is bad news. Maybe there's some sort of settings override? Worth a separate issue for that? (I thought *removing* features was considered creating a bug?)
Comment #5
joachim CreditAttribution: joachim commentedNot to mention that running just one particular update function is very useful when you're writing one for a module!
Comment #6
Damien Tournoud CreditAttribution: Damien Tournoud commentedOnly the UI has been removed. Drush could support running a single update if it wants to.
I suggest we wrap the update function with a try/catch and try to stop the update from here.
Comment #7
joachim CreditAttribution: joachim commentedIn theory, yes, drush could, but its output of errors has not so far been reliable. Core should not delegate important stuff to 'Oh yeah, contrib COULD do that if it wanted'.
Is there an issue where the removal of this UI was discussed? I can see that its removal makes updating a less scary task for newbies, but it would be nice to have it still in as an option.
Comment #8
DamienMcKennaFrom a usability standpoint the D6 workflow for this was fine - by default run everything but give advanced users an option to select the specific updates to run.
Comment #9
joachim CreditAttribution: joachim commentedIf the aim of removing this was to hide scary stuff, I'd be okay with having the advanced options only show if there's a ?display=advanced in the query string.
(or a better word than 'advanced', but you get the idea ;)
Comment #10
Damien Tournoud CreditAttribution: Damien Tournoud commentedAny contrib module can form_alter that form and get the dropdown controls back. There is no reason to restore a crappy UI, just for a few corner case uses.
The issue that removed the dropdown was #286035: Remove update.php number dropdowns.
Comment #11
greg.harveyI see why this has happened, but I think you both have a point. I think joachim is right it should *not* be up to contrib to create a sensible advanced update screen. But it could (and IMO should) be a core module that you can enable if you want advanced updates but is disabled by default (just like PHP Filter is in Drupal 6).
Comment #12
greg.harveyBtw, can we get *this* issue (schema_version updating when it shouldn't) back on track?
Moved the UI issue here: #595550: Advanced update options lost - re-instate as a separate module
Comment #13
Damien Tournoud CreditAttribution: Damien Tournoud commentedDifferent in scope, but related because it touches the same part of the code: #211182: Updates run in unpredictable order.
Basically, we will have to prevent the execution of all the updates that are after (in the graph exploration sense) the failed update.
Comment #14
stephencamilo CreditAttribution: stephencamilo as a volunteer commentedComment #15
hestenetReset issue status.