Forum OpenACS Development: Re: Upgrade and install management

8: Re: Upgrade and install management (response to 1)

Posted by Dave Bauer on 08/13/07 06:14 PM

If you want to make sure upgrades work across many versions please test them BEFORE we release. We rely on the community to test things obviously.

ie: "Last but not least, keep in mind that upgrades can fail because version 5.2.1 - 5.2.2 makes an assumption that is not true anymore in 5.4.1, but breaks because the TCL procedures used in the 5.2.1-5.2.2 upgrade behave differently now. This happened to me on acs-subsite and a couple of times on XoWIKI. And yes, you should not have a system so out of date, but it still happens (and apparently it happens a lot, from my experience)."

This can be fixed by updating the upgrade 5.2.1-5.2.2 in 5.4.1 only. That makes the upgrade work fine, but doesn't break upgrades in other releases.

There is no way to test every permutation of versions.

You must backup. That IS the best practice. I still say if an upgrade fails, there is no way to reliably continue upgrades if one script fails. The database is in an unknown state. The only way to proceed is to ttart over, fixing the error. Is the user cannot fix it himself, they report the problem and ask for help, hopefully the upgrade file is fixed in the next release.

9: Re: Upgrade and install management (response to 8)

Posted by Malte Sussdorff on 08/13/07 07:33 PM

Dave, to be honest, the easiest thing for me was to remove the offending upgrade from both the callbacks (as is the case with XoWIKI) or the upgrade directory. And whenever I stumble upon such a thing I silently commit to OpenACS on the latest release (as all future releases obviously would have the same problem).

Also note that we run into the same problem whenever we have dependencies on other packages (e.g. a change of PL/SQL function in acs-content-repository which the old upgrade script in acs-subsite does not know about).

Either way, I take from this discussion the following guidelines for the developers:

a) Use TCL callbacks to upgrade whenever possible, do not use the SQL upgrade directories
b) Wrap your TCL callbacks in a db_transaction (and yes I know you are saying this does not help when it fails, but at least I do not have to fix it in the database if all is rolled back).
c) Make sure you require the latest version of a certain package you depend on and check your upgrade scripts at least one major release back if it still works (read: are the procedures still there and is the DM still the same)

For the end users:
d) Make sure you upgrade every major release
e) Make sure to backup before running the upgrade
f) Do not upgrade from the acs-repository (as it fails for too many users it seems).

10: Re: Upgrade and install management (response to 8)

Posted by Malte Sussdorff on 08/13/07 07:38 PM

It might (and I say "might" here with major emphasis) be a good idea to require for a release to check at least two major releases back if the upgrade script is still needed. Examples would be

- PL/SQL definitions (if superseeded later)
- View definitions (if superseeded later)
- Creation of later dropped content types
- Creation of anything if it was dependent on a certain version of a package and that has changed in the depending upon package.