I was wondering if the latest DRUSH supports multi-pass (batch?) DB updates. For example, the date module recently had an update that required you to run update.php twice. Will Drush handle these updates in one pass, or do I need to run updatedb twice to be sure? Thanks for any info.

Comments

owen barton’s picture

owen barton commented
Status: Active » Fixed

You will need to run updatedb twice in these cases - drush has know way of knowing if some module expects updatedb to be run twice!

chrisschaub’s picture

chrisschaub commented

Yeah, thought so. Ok. They should really make this type of multi-pass updating considered "bad practice" since it makes updating large numbers of sites a real drag and error prone. I can't imagine a situation where this type of update couldn't be coded to support one pass.

Oh well, thanks!

moshe weitzman’s picture

moshe weitzman commented

I can't imagine a situation where this type of update couldn't be coded to support one pass.

You don't have to imagine. Look at the date.module update function. If you can rewrite it to work with one pass, then please inform us. If you can't, then perhaps you should just assume the developer knows what she is doing.

adrian’s picture

adrian commented

From the date_api.install 

 drupal_set_message(t('date module cannot be updated until after Views has been updated. Please return to <a href="@update-php">update.php</a> and run the remaining updates.', array('@update-php' => base_path() .'update.php?op=selection')), 'warning', FALSE);
    $ret['#abort'] = array('success' => FALSE, 'query' => t('date.module has updates, but cannot be updated until views.module is updated first.'));

i think we might be able to do smething about it, because the date module doesn't have control over which order the module updates are run in, but we do.
It's a very special case, but if we can find a couple of modules that have this problem, that all implement the #abort thing in the same way, we could just code it so it doesn't pop those updates from the stack, but iterates through them again at the end.

owen barton’s picture

owen barton commented

One fairly easy approach would be to repeat the update process, kind of as a "confirm" step, but also so we could catch this kind of update dependency. We could just repeat it until there are no further updates or we hit some infinite loop-breaker limit (e.g. 3 or 4 updates).

chrisschaub’s picture

chrisschaub commented

Hey, I meant no malice, and I didn't say someone doesn't know what they were doing. Is it not ok to question something? I was just suggesting that this sort of thing should be avoided, not become a trend. I'm worried that we'll start seeing more of these types of updates. Even from the interface, it's easy to miss the 2nd pass link. Ok?

chrisschaub’s picture

chrisschaub commented

I like this approach in #5, simple. Right now, I'm adding a few extra updatedb call just to make sure, but I could miss one if a few modules did multi-part upgrades.

If you did this, would it be possible to have the updatedb routine not spit out modules that had no update, unless verbose was turned on? It might be a lot coming across the screen to see the "No database updates for module ..." unless someone wanted to see that?

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

fonant’s picture

fonant commented

Be careful with potential infinite loops. A bug in date.install that affected people upgrading several minor versions at once caused a never-completing "please try again" loop (see http://drupal.org/node/535270).