Forum OpenACS Q&A: OpenACS Core Team Summary for 14 Jun 2005

Collapse
1: OpenACS Core Team Summary for 14 Jun 2005
Posted by Joel Aufrecht on 06/14/05 07:05 PM
Present: Don, Dave, Joel, Jeff, Malte, Caroline, Rocael

1. Releasing 5.2. The outstanding tasks from last week are still outstanding. Rocael reports progress. Joel to convert any remaining problems to blocking bugs, and to triage the 5.2 bugs.

2. Reviewed outstanding TIPs.

Collapse
2: Re: OpenACS Core Team Summary for 14 Jun 2005 (response to 1)
Posted by Andrew Grumet on 06/15/05 04:09 PM
I did some testing of the Oracle upgrade last week and I believe this still needs quite a bit of work. I was unable to upgrade a bare instance + file-storage. Upgrading the kernel package only left numerous kernel plsql packages in an invalid state, causing downstream plsql scripts to fail with "existing state of package has been discarded" errors.

I'm pretty sure this can be fixed by more aggressively pasting package body definitions into upgrade-5.2.0d1-5.2.0d2.sql in kernel. I started on this last week.

Collapse
3: Re: Re: OpenACS Core Team Summary for 14 Jun 2005 (response to 2)
Posted by Andrew Piskorski on 06/15/05 07:43 PM
Why are people still always copying PL/SQL package definitions into upgrade scripts? AFAICT, most of the time, an upgrade script should simply source the canonical definitions of PL/SQL (or plpgsql) code or views, as I discussed back in 2003. Is there some good reason I am missing here why OpenACS upgrade scripts instead so often verbosely copy-and-paste code?
Collapse
4: Re: OpenACS Core Team Summary for 14 Jun 2005 (response to 1)
Posted by Andrew Grumet on 06/16/05 03:26 PM
Yes, there is. When you're doing multi-version upgrades, the "canonical" version is really "the canonical version for the most recent version of the package which may be different from the version that the original upgrade script was tested against." The only way to protect against version skew is to copy in the package definition as it existed at the time the upgrade script was written.

Now, this can be difficult to maintain if the package definition itself is in flux at the time the upgrade scripts are being written. I suspect we could find a way to manage this through coding conventions and or directory layout conventions (e.g. save a copy of every canonical version in systematically named directories) if there was interest.

Collapse
5: Re: OpenACS Core Team Summary for 14 Jun 2005 (response to 1)
Posted by Dave Bauer on 06/21/05 06:29 PM
Is there a way to upgrade past more than one version sucessfully on oracle without recreating the entire package for each version? If you are just upgrading from the last, to the next version, there is only one SQL file containing the pl/sql packages, but if you upgrade more than one version, it can cause problems.