My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 578: Schema update
  Back to list
Status:  Released
Owner:  ----
Closed:  Oct 2012


Sign in to add a comment
 
Reported by rafael.rabelosilva@sonyericsson.com, May 25, 2010
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
I thought we already did this.

Init implements UpdateUI and overrides pruneSchema to
collect the unique SQL statements into a List.  That
list is reviewed to the user at the end of the update
and then executed.

But, your solution of only running the lower level
ORM version of pruneSchema during the final schema
update class seems more elegant.  So if you have code
ready to share I would be interested in reviewing it.
Status: AwaitingInformation
May 27, 2010
#2 rafael.rabelosilva@sonyericsson.com
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
#3 sop@google.com
Yes, if you have a more elegant solution, I would like to
use that instead.  :-)
May 27, 2010
#4 sop@google.com
Fixed in Ib6e8eb84e142c4c551703c0a532ad74c09d6b71d
Status: Fixed
Labels: FixedIn-2.1.3
Oct 21, 2012
#5 sop@google.com
(No comment was entered for this change.)
Status: Released
Sign in to add a comment

Powered by Google Project Hosting