Forum OpenACS Development: Oracle out of sync
If this continues we should most likely drop Oracle support unless we certify a release to work with Oracle (and organisations interested in using Oracle need to dig and find out which files from PostgreSQL are missing).
My *preference* though would be to encourage all developers to just copy the postgresql files to the Oracle directory. This will *visibly* break the upgrade for Oracle on upgrade, making it easier for developers to find what is missing.
Last time I proposed this there was adamant disagreement from Dirk, but sadly no better solution has arisen since. And if you look at the CVS commits, there are a couple of commits that do not include an equivalent Oracle file, letting Oracle based versions upgrade smoothly and then choke you to death when trying to use the application. And this sucks, because you *assume* the upgrade worked (no error on upgrade). And if you are not doing very close testing on your staging site before applying the upgrade on Production, you run into big troubles.
Therefore I ask for feedback from the developer community how to fix this. And no, Encouraging everyone to commit Oracle scripts will not work. Most developers do not have access to Oracle even if they care, and even more might not care at all.
Hard as this sounds, we should make it as easy as possible for developers of institutions using .LRN on Oracle to go and fix the scripts, as experience shows that they are the ones who have to do the work anyway.
Oh, and to be fair, if something has been developed on Oracle, you might just as well copy that script over to postgresql and have it break there. My guess is it will be fixed within 24 hours :).
begin raise_application_error(0,'Upgrade upgrade-5.2.0d8-5.2.0d9 needs to be ported to oracle'); end; /and put it in the oracle upgrade directory named properly.
Putting the pg script in means you might end in some wierd (hard to fix) state.
cp upgrade-5.2.0d8-5.2.0d9 ../../oracle/upgrade
Won't the raising of an error, as Jeff describes, trip the APM and force it to fail without completing the upgrade?
Also, just how many long-term OpenACS core developers do not have both Oracle and PostgreSQL installed on their development machines? I'm kind of shocked that the number would be much greater than zero.
I've only ever really CVS committed one significant set of changes to OpenACS (the multi-db support), but back then, I most certainly did set up both Oracle and PostgreSQL for my testing, even though I never use PostgreSQL in my own work. Also, I recently installed Oracle 184.108.40.206 (but have not yet published my notes on the process), and frankly, it wasn't bad. Much, much easier than installing 8i.
Doing upgrade scripts for both databases is certainly extra work, so I can understand if/when some developers skip that. But using "I don't have Oracle installed" as an excuse? No way, that doesn't cut it.
if I get paid work for oracle but all the contracts we have
had have been pg based for a while (in part since we don't
The problem is that Postgres has gotten so good that there's not a strong argument for deploying Oracle as the back end for OpenACS any more. Greenpeace, for instance, is moving Planet (greenpeace.org) to Postgres as part of the Planet II development project.
Frankly, if it weren't for .LRN I think we could get an TIP passed to scrap Oracle support ...
For anyone with the technical skills that I suspect, hope, and assume most of the core OpenACS contributors have, and unless my 9i install experience was grossly atypical (which is somewhat possible, as I was using an ancient Red Hat 7.3 box), installing a development-grade Oracle instance probably boils down to no more than an afternoon or two of work, maybe once or twice per year.
What is the biggest obstacle preventing better Oracle support? Install docs for 9i and 10g? What? If there's something I might be able to do to help improve OpenACS Oracle support, I definitely want to at least know what it is...
I would never vote for anything this drastic. We have to support upgrades.