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.
------------------------------------------------------------------------------
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!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
