Forum OpenACS Development: Issues with big upgrade

Posted by Antonio Pisano on

I am trying to upgrade an application built for OpenAcs 5.5 to the 5.8 release. It is quite a big leap, and I am facing some expected issue.

The first is something I think had slipped through in upgrade scripts: /acs-kernel/sql/postgresql/upgrade/upgrade-5.7.0d8-5.7.0d9.sql seems to contain a syntax error (due to super quoting, I guess).

I have fixed it for me by replacing definition into the script with those found into /acs-kernel/sql/postgresql/postgresql.sql. Is there any problem with this solution? If not I can commit the change.

The second is more subtle and I can't figure out easily what to do: into ref_language::apm::after_upgrade, the system checks for new languages to add. In my database the Hebrew language already exists, with language id "iw". The upgrade tries to enter another row for Hebrew language with id "he".

As the two ids are different, checks for language uniqueness fail to see that this language already exists. The problem is that we have a unique constraint also on the 'name' column, so the upgrade throws an error.

I could not verify whether this bogus language was put into the database by hand or comes from the standard installation... if was put in there by "us", I could just remove the row. If this is not the case we need to put some code in there to handle the issue. Can someone give hints on this?

Posted by Antonio Pisano on
...just to see what could happen, I removed the fake Hebrew language from the table, then all went smooth to the end. Nice!

Will fiddle around a little and report my experience.

Posted by Claudio Pasolini on
Hi Antonio,

the upgrade script upgrade-5.7.0d8-5.7.0d9.sql has been written to be executed with PG 8.x and so I suspect that you were executing it with PG 9.x.

I did a lot of upgrades restoring the database from PG 8.2 to an intermediate PG 8.4, upgrading to OACS 5.8 and finally restoring from PG 8.4 to PG 9.x.

Posted by Gustaf Neumann on
The issue is/was the change in PostgreSQL versions rather than the OpenACS upgrade. As Claudio wrote, the recommended approach is first to upgrade with PostgreSQL 8.* to OpenACS 5.8 and then dump/restore in PostgreSQL 9 and continue.

We did not adapt the kernel update scripts for pg.9 since this would break upgrades for installations with earlier OpenACS/pg-versions (there are really many old and working installations in the free wild). The easy rule is that with OpenACS 5.8, the support for PostgreSQL 9.* begins.

I can't comment on the the language issue, but you it seems from your comments, that this was a local configuration issue.

Posted by Antonio Pisano on
Very well, all went as it was meant to be then. I will keep in mind the right procedure when I'm going to do this in production.

Thanks to both!