hook_update_N() are used to change the target database based on code. They can be used to develop websites completely in code using a module deployment module, in which case there can be hundreds of update hooks for a given project.

A problem occurs where more than one developer is working on the same code, and two developers define, say, mysite_update_7154(). This will often not result in a git conflict, but will break the tests. Furthermore, it is important that 7154 be ignored and that both instances of mysite_update_7154 be renamed to 7155 and 7156, so that both developers get the same updates.

One possible solution to this is for each developer to have his or her own dedicated module where changes can be made (for example enabling modules, reverting features and the like). Still, this does not feel elegant.

I can't find any documentation on this, but a colleague told me that Ruby on Rails deals with this by using timestamps instead of sequential ids for their equivalent of update hooks.

We could also have modules not remember on the _last_ update hook which was run, but keep track of all of them, so that developers could have their own system where dev 1 uses 7001, 7003, etc, and dev 2 uses 7002, 7004, etc.

Cheers,

Albert.

Comments

grom358’s picture

Yeah currently the system just keeps a schema version number of where it was upto in terms of running these update hooks. My thoughts instead of that it keeps a track of which update hooks it has run. And the hooks could be named instead of number to add to readable/documentation. Eg. myprofile_update_enable_mymodule() . So would have table that records which hooks it has executed.

Even better would be to take the migration idea (also in Ruby on Rails AFAIK) and apply that to the updates.. So update hooks can be rollbacked. In terms of Drupal 8 each update hook would instead be a class.

class EnableMyModule implements UpdateMigration {
  public function update() {
    module_enable(array('mymodule'));
  }

  public function undo() {
    module_disable(array('mymodule'));
  }
}
larowlan’s picture

kim.pepper’s picture

Rails follows a similar model to the above using timestamps instead of incrementing numbers. http://guides.rubyonrails.org/migrations.html

Rolling back is not always possible, when you are making destructive changes. In which case you can throw an IrreversibleMigrationException on down().

Having migrations in separate files would be a huge benefit.

catch’s picture

Version: 8.0.x-dev » 8.1.x-dev

https://www.drupal.org/sandbox/catch/2337361 is a 7.x hack but handles the same need.

Also we now have post update hooks which aren't versioned (but also don't support dependencies etc. yet).

phenaproxima’s picture

I'd like to see something like what @grom358 proposed -- the ability to go forward and backwards. I've never run into versioning conflicts, but that's just because I work on a smaller scale than most. And I agree with @kim.pepper about disallowing rollbacks for destructive updates, although it'd also be good to warn users beforehand.

dawehner’s picture

I'd like us to not try to solve everything ever possible at the same time, this just results in too much of work and results in no progress at all.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

andypost’s picture

If update tasks are timestamp or post_update hook name, so they can be similar to proposed install tasks #2234315: Dependency graph resolved plugins for installer tasks

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

effulgentsia’s picture

This issue predates #3167625: Deprecate/replace hook_update_N() in favor of an object-oriented approach similar to Laravel migrations, but that one has a more detailed issue summary. Anyone object to this issue getting closed as a duplicate of that one, and centralizing further discussion over there?

cilefen’s picture

I just read this over. I think a better, timestamp based system would alleviate some of the friction detailed in the issue summary. But I don’t know today of a migration system that is timestamp based but that also automatically solves the ordering issue—meaning, when the order of applied migrations matters.

So IMO this should be postponed and narrowed in scope to solve whatever DX cannot be solved via #3167625: Deprecate/replace hook_update_N() in favor of an object-oriented approach similar to Laravel migrations

catch’s picture

The proposal in #3167625: Deprecate/replace hook_update_N() in favor of an object-oriented approach similar to Laravel migrations does mention that update dependencies would be a must-have of any new system, and I don't think that should be handled separately - needs to be addressed at the very beginning, so happy with closing this as a duplicate. Having said that I'm not convinced about the class vs. timestamp mismatch in the other issue, but that's something that can be thrashed out in one place too.

alberto56’s picture

Status: Active » Closed (duplicate)

I had created this original issue and I can confirm that all of my preoccupations can be addressed in #3167625: Deprecate/replace hook_update_N() in favor of an object-oriented approach similar to Laravel migrations, so based on that fact, and the above comments, I will close this a duplicate. Thanks everyone.