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?

Regards,

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.