Forum OpenACS Development: Error upgrading OpenACS 5.7 to OpenACS 5.9

Request notifications

Hi!

We've got an issue upgrading the Content Repository to 5.9 with content_type__refresh_view referencing ams_object_revisions. I'm not sure if that's correct or not, just FYI:

PL/pgSQL function "content_type__refresh_view" line 94 at PERFORM
psql:/web/po40dev/packages/acs-content-repository/sql/postgresql/upgrade/upgrade-5.9.0d3-5.9.0d4.sql:117: ERROR: relation "ams_object_revisions" does not exist
LINE 16: ...ons.* from acs_objects, cr_revisions cr, cr_text, ams_object...

Collapse
Posted by Frank Bergmann on
We've got a second one, maybe related to the removal of tree_sortkey from acs_objects. This is just FYI, just wanted to post the issues here:

psql:/web/po40dev/packages/file-storage/sql/postgresql/upgrade/upgrade-5.8.1-5.8.2.sql:10: ERROR: column o2.tree_sortkey does not exist
LINE 6: and o2.tree_sortkey between o1.tree_sortkey

Collapse
Posted by Frank Bergmann on
acs-admin apparently has an issue in apm-admin-init. It seems the table generation lacks semicolons, at least they hit the DB literally without them...

::xo::db::require table apm_package_downloads {
time timestamp
ip text
user_id integer
channel text
package text
version text
url text
}

Here is the error:

[04/Dec/2015:15:24:55][29352.1353279232][-main-] Notice: Querying 'create table apm_package_downloads (
time timestamp
ip text
user_id integer
channel text
package text
version text
url text
);'
[04/Dec/2015:15:24:55][29352.1353279232][-main-] Error: Ns_PgExec: result status: 7 message: ERROR: syntax error at or near "ip"
LINE 3: ip text
^

Collapse
Posted by Gustaf Neumann on
This is apparently the same issue as in [1]. I'll try to explain in more details:
- The drop of attribute tree_sortkey in acs_objects requires to regenerate all views including blindly all attributes of acs_objects (including e.g. "acs_object.*" in the output variables of a view)
- Such a view is created e.g. for all acs-object-types in OpenACS.These views are generated via the SQL function content_type__refresh_view. This function works only with correctly setup of the acs-type and attribute definitions. Unfortunately, some unmaintained packages have incorrect type definitions, which cause content_type__refresh_view to raise an error. One example of such an broken package is edit-this-page, which i have fixed, since it is used on openacs.org. The fix for this package is in [2], the package had registered non-existing table names which had to be dropped.
- AMS belongs to the unmaintained packages and has probably a similar problem.
- When the mentioned upgrade script (mentioned in your first posting in this thread) rises an error, one has either to fix the problem, or run tcontent_type__refresh_view manually on all oacs-types. Otherwise, some views will be missing.

Concerning message #2: it seems that you did not follow the upgrade recommendations of [3] and [4], but you are trying to run upgrade scripts of 5.8 on the 5.9 kernel. It is recommend to upgrade first all packages to the latest releases of OpenACS 5.8, and then upgrade the kernel (this addresses as well the etp issue mentioned above).

Concerning message #3: it seems that you are running on that system an old version of xotcl-core. In the particular case, this does actually not matter, since this init file is just required for openacs.org, you can delete the file in your packages completely.

[1] http://openacs.org/forums/message-view?message_id=4868272
[2] http://fisheye.openacs.org/browse/OpenACS/openacs-4/packages/edit-this-page/sql/postgresql/upgrade/upgrade-1.9d2-1.9d3.sql?r=1.1]
[3] http://openacs.org/xowiki/upgrade-oacs-5-8
[4] http://openacs.org/xowiki/upgrade-oacs-5-9

Collapse
Posted by Frank Bergmann on
Hi Gustaf,

I - more or less - understand your explanations. However, we'll need a "solution" suitable for our sometimes not very technologically sophisticated users. We'll somehow need to make sure that users can go through the upgrade procedure without "seeing" error messages. We've got some 6.000 productive installations to deal with...

What are the options?

- The easiest way is probably to "fork" and modify the OpenACS upgrade scripts in order to catch the special cases.
- Maybe we could "clean up" stuff before actually running the upgrade scripts, for example in the case of AMS?
- Anything else?

Would it be possibility to consider a ]project-open[ installation in the future when developing the upgrade scripts?

Cheers,
Frank

Collapse
Posted by Gustaf Neumann on
Do you need AMS? It seemed to me, that you did not need ref-itu which also caused problems.

In case PO needs AMS, a person is required that is sufficiently familiar with AMS to fix it (i.e. to provide an upgrade script like the one i did for etp, maybe this could be as well just a one-liner). The upgrade script (with a bump in the AMS version number) should go into the CVS repository. Then an upgrade to the latest version version of all packages in an OpenACS 5.8 installation will fix this problem. After this the upgrade to OpenACS 5.9 will go smooth.

Collapse
Posted by Frank Bergmann on
Hi,

Nope, we don't need AMS at all.
AMS used to be the base of "DynField", which is the ]po[ SQL metadata system.

I have no idea why there are still AMS elements in the system. I'll check. That's something we can clean up before the actual upgrade starts.

Thanks!
Frank