Closed (fixed)
Project:
HEAD to HEAD
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
12 Sep 2010 at 17:10 UTC
Updated:
20 Mar 2015 at 15:34 UTC
Jump to comment: Most recent, Most recent file
Recently there have been some patches to core which renumbered/reorganized existing update functions:
- #898536: Clean-up the upgrade path: dblog is an example of one which was committed.
- #909272: Remove stub update functions and renumber the remaining ones is an example of one which (if committed) would add a bunch more to the list.
This could leave existing D7 sites with a schema_version in the database that is too high, meaning that future update functions for that module will not run on it.
To fix this, we probably just need a helper function which, for each installed module, compares drupal_get_installed_schema_version() with drupal_get_schema_versions(), and if the schema version in the {system} table is higher than the maximum one defined by the module, update the {system} table to reset it back down. And perhaps with some tweaks to reflect the fact that some update functions which were added to core recently actually do need to run on existing D7 sites, so set the schema version accordingly lower for those particular modules.
We also might want to look at any hardcoded calls to particular core update functions contained within the HEAD to HEAD module, and see if those need to be changed because the update function was renumbered.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | locale-schema.patch | 733 bytes | gábor hojtsy |
| #3 | locale-schema.patch | 783 bytes | gábor hojtsy |
| #1 | head2head-schema-versions-909338-1.patch | 3.96 KB | David_Rothstein |
Comments
Comment #1
David_Rothstein commentedCommitted the attached patch.
After careful examination, it turns out there were no special cases here, just dblog and comment both needed their schema versions set back.
I took the conservative approach of requiring the calling function to specify exactly which modules they wanted to check, so other modules (e.g. custom modules on the site) don't accidentally have anything funny happen to them when the update is run. If other core modules have their update functions reorganized and renumbered before beta, we'll have to update the list in the alpha2alpha update function accordingly.
Comment #2
David_Rothstein commented#909272: Remove stub update functions and renumber the remaining ones was committed recently. It removed locale_update_7002(); I think that's the only change we need to worry about here (but haven't looked super-closely).
I think we just need a new alpha2alpha update to call the same head2head function for 'locale'. And then we need to keep an eye out and see if locale_update_7002() gets added back before the Drupal 7 beta release, in which case we might need to do something different here :)
Comment #3
gábor hojtsyIndeed, looks like this will be enough. Committed. Let's keep this active so we can monitor it. Marking needs more info for future tracking.
Comment #4
gábor hojtsyWups, my checkout was outdated, here is the right patch.
Comment #5
David_Rothstein commentedClosing as fixed (well half-fixed and half-not-fixed), since no one is likely to need Drupal 7 HEAD to HEAD upgrade path patches anymore, and to clear out the queue for possible Drupal 8 usage (#2455949: [policy, no patch] Re-activate the head2head project and use it for beta2beta upgrades in the short-term).