Forum OpenACS Development: Re: Towards OpenACS 5.9
If you can't test oracle, by definition it no longer works.
The Oracle-based people have, for over a decade, screamed at the mention of dropping Oracle but have never offered significant resources to keep support current (though one company, when they learned I was doing so for core single-handedly on a volunteer basis, did give me a small gift as a token of appreciation. Not enough for even one decent dinner but I did appreciate it).
"We should try to get in touch with these to assess their situation" - post a thread stating "we're talking about dropping Oracle again!!!!" and see if anyone screams. If not, you're in the clear. If so, tell them to step up and maintain the damned thing.
I'm guessing that the various legacy users of oracle-based .lrn, for instance, haven't upgraded in a long time. I'm 99% certain that's true of UNED (Emmanuelle's no longer there, and in her last years there had nothing to do with the maintenance of the .LRN installation there - despite encouragement to upgrade, last I heard they were stuck on a version that's about five years old).
So if you investigate I think you'd find that any existing oracle usage is legacy usage, and already orphaned.
I could be wrong but it would simplify what's left of the project, and given the lack of resources now that most of us have moved on, would seem like a smart thing to do.
All recent development on OpenACS passed through the uneasy task of considering Oracle people still around, so it would be better if such struggle could end up useful.
Andrew, what would you guys ngals think of having to move to postgres soonish?Not going to happen, not anytime soon, and maybe never, for a variety of reasons.
Folks, keep in mind that we don't use our RDBMS just for a website, and I suspect this is pretty common for other small firms out there.
In our particular case, we use Oracle extensively for other non-OpenACS non-web data management. We take advantage of OpenACS to view, help maintain, etc. that data. Essentially, in addition to the other ways we use it OpenACS provides a UI to that data. It all lives in the same Oracle instance, in different table spaces.
When we were starting with this back in 2001, PostgreSQL wasn't quite ready for our needs and ACS/OpenACS 4.x didn't yet support PostgreSQL anyway. I'm told that PostgreSQL now supports the SQL:2003 OLAP (windowing, lead/lag, etc.) features, which are incredibly useful when dealing with financial and other time-series data. So if we were starting from scratch today, perhaps we'd go with PostgreSQL rather than Oracle. But not necessarily, it depends.
Many third parties - like data vendors - still support Oracle but not PostgreSQL in ways that can matter. E.g, in my experience most data vendors essentially just give you obnoxious, giant, completely de-normalized CSV files. The better ones (or perhaps the ones with the most complicated data) pre-specify a reasonable relational schema, and often provide their own loader tool to keep it updated. We use one which only supports Oracle and MS SQL Server. (Could they add support for PostgreSQL if they wanted to, or even SQLite? Probably, but so far they haven't.)
With a data vendor like that, do you have to use their loader? Often, no, but if you don't, you get to handle all the work of processing their internal-format transactional update files multiple times every day, etc. etc. None of that is insurmountable. But it is an example of why it is valuable to have a nice toolkit that just so happens to support the RDBMS that you also want to use for other reasons.
Should you care about this? About our specific needs, perhaps not. But I hope it least illustrates how the "legacy" feature of good support for both Oracle and PostgreSQL may be of more value than the typical PostgreSQL-only OpenACS user appreciates.
By the way, Oracle has ended up working well for us, but we didn't know that it would ahead of time, nor could we have, since we didn't even know many of the details of our own needs yet. (Heck, I didn't even know that lead, lag, and all the other SQL:1999 and SQL:2003 OLAP functions existed until 2001, and now we critically depend on them.)
In that situation, which I think is pretty common, the right approach is to bias your choice of tools towards flexibility. So which would sound like a better bet to you? "We only support one RDBMS, period." Or, "We support two of the most powerful and full-featured RDBMSs available, PostgreSQL and Oracle."
Back then, I was certainly thinking about the fact that if we ran into some unexpected major roadblock with Oracle, we might be able to get around it with PostgreSQL. The same feeling in the opposite direction might be more common.
None, is my guess.
Back when I was maintaining Oracle support, did you ever offer to help pay for my time? Or, when the subject was ever raised, did you just post as you have posted now: "we need oracle support, don't drop it!"
"Should you care about this? About our specific needs, perhaps not. But I hope it least illustrates how the "legacy" feature of good support for both Oracle and PostgreSQL may be of more value than the typical PostgreSQL-only OpenACS user appreciates."
Sure, valuable to you and other freeloaders. But the reality is that for over a decade, almost all of the financial and programmer resource support has come from those using PG.