Forum OpenACS Development: Re: Error upgrading OpenACS 5.7 to OpenACS 5.9
- 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 , 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  and , 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.
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?
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.
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.