Forum OpenACS Development: cleaner upgrades: refactor refactor! upgrade scripts by pg version, etc

Collapse
1: cleaner upgrades: refactor refactor! upgrade scripts by pg version, etc
Posted by Jim Lynch on 06/07/04 03:34 AM
Excuse the ramblyness of this; I cane up with it while on IRC...

you know already what's -really- needed... is explicit differentiation between versions of postgres.

forexample

if we can provide 4.6.3 with a way to upgrade its database to 7.4.2 using extra directories named for postgres version and that have upgrade scripts that are sensitive to the "from" and "to" versions of pg, then this whole upgrade process can be made clean

as it is (and as we all know), each upgrader (from say 4.6.3 on pg-7.2.x, to pg-7.4.x. oacs-5.1) is getting somewhat different results (even now after a year or so), which are partially based on what was done before... but mostly on what packages are installed.

one example of a weirdness is this application_users table or view, which is created by an acs-subsite data model script that is no longer sourced, which means if there's a really old openacs that has this view, maybe the upgrade script doesn't deal with it, or if it was newer and the view was never added, the upgrade scripts might try to deal with it, and cause errors because of that.

This happened to me while I was upgrading, and there just isn't enough information to know whether an error like this is significant and indicates an actual problem or not. The problem this causes makes openacs less accessable for new people; I'm hoping this message will generate ideas for cleaning up and refactoring the install and/or upgrade process.

Another issue is the upgrade scripts of (for example) the kernel mess with stuff in other packages. maybe this is necessary, but perhaps it's just expedient to put these things (other-package stuff) into the kernel scripts... if there were some way of having (for this example) the kernel be sensitive to the other packages installed, upgrading the kernel could be cleaner, or just plain clean.

People will groan at this, as I myself am, because it's a LOT of work, but here's some of what I'm thinking.

  • maybe the upgrade scripts could be divided and factored
  • an upgrade script could ask the db, "is foo installed,"
  • if yes, call up a script that perhaps was factored out of the kernel because it was really part of foo
  • this script in foo is just the little piece that was factored out, and so you introduce granularity just where it's needed
  • another example, the user could have asked to upgrade the (forexample) pg version, so the upgrade would have to take a somewhat different path
  • this part would take total care of issues like
    • length of pg identifier names (because it would know that pg7.2 has shorter names than 7.4)
    • timestamp going to timestamptz (because the upgrade would be sensitive to the point at which timezonetz was needed)
    • etc ...

What I think this would gain us is more users that can actually do the upgrade because openacs would be able to do it cleanly and with sensitivity to versions.

small detail, user would have to tell the upgrade using some sort of UI that "I want you to upgrade the database. The one you're on is the pg version to upgrade from, and here's the pg (which could be on another machine) and database to upgrade to" (the user would type that info into a text form box).