Re: Migrating from 1.3.30 to 1.5.3

Hi Bill,

Thanks for coming to the chat room as suggested by David. It's great that we were able to work out the problems you were running into. We'll be including the required fixes in the next (and following) 1.5 release for others to enjoy.

Summarizing the problems we were having:

1. The migration process in 'setup.pl' complained about errors

2. The migration from 1.3 to 1.5 had two bugs

3. You were seeing authentication problems through Apache (but not directly on Starman)

Ad 1.
The database imported on the new system had permissions which prevented the pre-migration checks from being run successfully. After fixing the import to be owned by the 'lsmb_dbadmin' user, this problem was resolved. The development team considers the options to provide built-in import functionality in order make sure the correct commands (resulting in the right ownership) are executed.

Ad 2.

One bug was simple: an unquoted constant was taken to be a column name. Quoting the constant solved the problem.

The other bug was similarly simply solved: data couldn't be migrated due to an integrity constraint; by migrating the data in two steps, the migration could be completed. This bug however, shows a design problem in the 1.3/1.2/SQL Ledger->1.5 migration process. The team is now working out how to best fix this design problem. For the time being, the fix as used for your migration will be used as it will enable migrations at this point.

Ad 3.
The Apache reverse proxy configuration needed to be extended with CookiePath and CookieDomain reverse proxy statements. When these were solved, you were unable to see that they were, because by that time, you were receiving authentication failures due to your session being expired.

We'll include the ProxyPassReverseCookiePath and *CookieDomain settings in the example Apache setup in the release.

Kind regards,

Erik.

On Mon, Feb 27, 2017 at 10:27 PM, Erik Huelsmann <..hidden..> wrote:

Hi Bill,

On Mon, Feb 27, 2017 at 8:27 PM, bill Ott <..hidden..> wrote:

Hi, Erik. Apparently I am not migrating this properly. The version from the SQl select command was 1.3.30.

I moved the database by doing "pg_dumpall -c > dumpdata" from the 1.3.30 system but using the pg_dumpall program from the 1.5.3 system. I then issued "psql -f dumpdata postgres" on the 1.5.3 system. Then logging into the 1.5.3 system with psql and executing a "\l" shows all of the databases. BUT, the version field from default is 1.3.30
Ok. That explains at least some of it. Which instructions have you been using for your migration? Can you provide some details as to how you handled each of the steps in the instructions? Having that information will help me understand where you're currently at with your migration.

Very odd the every select I tried on the database works correctly even though the version is the old version.
Right. You made an exact copy of your database. Which means that all queries should work as they did under 1.3.

How should I proceed? Can I just use SQl to modify the version field, or would that just be making things worse?
Just changing the number through an SQL statement will not help to resolve the situation: the new software won't know it's talking to an old database version, leaving them in Babylon.

--
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.

Bye,

Erik.

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

Robust and Flexible. No vendor lock-in.