Hi,
Following up to our discussion on IRC, I've just pushed the initial changes required to get a 3.0 to 1.4 migration going. Here are some details you also need to understand before being able to do your own work.
The upgrade process is run from
setup.pl: simply connect to your sl30 database (preferably a copy!) using LedgerSMB's
setup.pl; you'll be asked if you want to migrate. If you click "Yes" the following happens:
* Setup.pl runs the pre-migration checks from LedgerSMB/Upgrade_Tests.pm, matching the 'sql-ledger' appname and has a version between min_app_version and max_app_version.
* The pre-migration tests succeed if there are 0 (zero) returned rows.
* The pre-migration checks can offer 1 column of data to be corrected
* when the pre-migration checks finish, the public schema gets renamed to 'sl30'
* a new "public" schema gets created
* the new "public" schema gets populated with the LedgerSMB schema (sql/Pg-database.sql and sql/modules/*.sql files)
* the file sql/upgrade/sl3.0-1.4.sql gets processed and run as 'upgrade.sql'
All output is stored in log files in /tmp/ledgersmb; the /tmp/ledgersmb directory regularly has incorrect permissions -- if a migration fails, you want to start by checking that.
Also, in the logs you'll see loads of Fixes.sql errors. That's expected: those are from changes which have already been incorporated in the schema. In 1.5 we have a much better mechanism in place to apply schema changes, eliminating all the error clutter.
My own tests with 3.0 (without data) ran into a problem in the migration file with some table missing a 'role' column which exists in 2.8, but apparently no more in 3.0.
You can reach me in #ledgersmb on freenode, or through this mailing list through e-mail for details on the LedgerSMB internals.
Thanks for offering your help!
Regards,
--
Bye,
Erik.
Robust and Flexible. No vendor lock-in.