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?
Robust and Flexible. No vendor lock-in.