| Issue 578: | Schema update | |
| Back to list |
Affected Version: 2.1.2 What steps will reproduce the problem? 1. Suppose the latest schema version is the 32nd one. 2. Create a new schema version (the 33rd one). 3. In the Schema_33.migrateData method, consider an ALTER TABLE is executed to drop a column (let us suppose the submit_type column of projects table, and also considers the Project class is updated to not have this column). 4. Consider now the code is compiled (mvn package), a war file is created). 5. Consider you have a gerrit installed with the database using the 30th schema version. 6. Execute the init to the war file you have generated in the 4th step. What is the expected output? What do you see instead? I believe the expected behavior is to correctly update the schema version (from 30 to the 31, from the 31 to the 32, from the 32 to the 33), without warning the user of unused objects. However, it warns the user there are unused objects, since from the 30 to the 31, and from the 31 to the 32, the unused column to be dropped on the transition of 32 to 33 is seen (was not dropped yet). In case this is accepted, my suggestion is to only 'prune schema' in the 'transition' to the latest schema version (the one specified in the SchemaUpdater.update call). So, it would be required to update the SchemaVersion class, executing the following changes: - add a boolean toTargetVersion parameter to the check method - add a boolean toTargetVersion parameter to the upgradeFrom method - in the upgradeFrom method, only 'prune schema' if toTargetVersion is true - in the upgrateFrom method, always call the check method with the false value to its fourth parameter (toTargetVersion) In the SchemaUpdater.update method, call the check method with the true value to its fourth parameter (toTargetVersion). PS: I already did as my sugestion locally, if approved I can submit immediately.
May 26, 2010
#1
sop@google.com
Status:
AwaitingInformation
May 27, 2010
Hi Shawn. Yes, the list is reviewed to the user at the end of the update, but it could be unnecessary to populate it in a situation like the one I showed you (populating it before the final schema update). So, can I ask Ulrik Sjölin to upload the code to review? Thanks. Rafael.
May 27, 2010
Yes, if you have a more elegant solution, I would like to use that instead. :-)
May 27, 2010
Fixed in Ib6e8eb84e142c4c551703c0a532ad74c09d6b71d
Status:
Fixed
Labels: FixedIn-2.1.3
Oct 21, 2012
(No comment was entered for this change.)
Status:
Released
|
|
| ► Sign in to add a comment |