[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Reviewing / writing upgrades to 1.5

In preparation for the 1.5 release, I'm testing the migration from LSMB 1.3 & 1.4 -> 1.5 as well as SL 2.8 and 3.0 -> 1.5 (and ideally, 1.2->1.5). Today I've started with 1.3->1.5. Most resolutions to my findings are on my 'master-migrate-improvements' branch. My review brought me to a deeper issue that I'd like to share my thoughts about with you and hopefully discuss.

The issue is this: In the past we have had a Fixes.sql file, which contained (small) schema changes. Adding or removing constraints, sometimes adding a column or dropping something obsolete. There's a migration challenge in that: we have a "floating source" (slight changes within the 1.3 series) *and* a "floating target" (slight changes in the schema within the 1.4/1.5 series); however, we have always dealt with a single migration script to migrate all these versions. This hasn't caused us any problems so far (that we know of), but it *could* in the sense that we tested with a working migration version while other combinations might not work.

This isn't necessarily the case any more in 1.5: There we start with a base schema that is the same on all versions. Then we have a list of schema changes to be applied to that base schema.

Notice how we have the opportunity to have a solid schema version to migrate to: the 1.5.0 base schema. In order to actually use this property of the new schema upgrade methods, I'm thinking we should change the upgrade to do the following:

 * Load base schema (but not the stored procedures, because they depend on the changes having applied)
 * Run the data migration
 * Load the schema changes
 * Load the stored procedures

Now, since all the schema changes have a well defined lower and upper bound (other changes between which they need to be applied), this should now provide us with a solid migration path where there should no longer be the need to continually adjust migration scripts to match the "migration end-point".
There may be a need to adjust to new versions coming out in the 1.3/1.4/SL series, though. We might want to think about how to support that scenario.

There are some questions that arise though when we do the above:

 * In the 1.4 series, each time we create a release, we update the version number in Pg-database.sql; if we do the above, we should stop doing that. Does that cause problems elsewhere?
 * If we stop doing the above, then how does the new version number get into the database?

Questions that I have that are unrelated to the above:

 * Am I correct that there's no need to have a 1.4->1.5 upgrade file, because we have fixes.sql as changes now?
 * Is the alternative to upgrading from 1.4->1.5 then simply "rebuilding modules"?
 * Should we call "rebuilding modules" something different, since it *might* include data migration?




http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
Ledger-smb-devel mailing list