Forum OpenACS Development: Re: Re: Re: OACS 6 and beyond

Collapse
Posted by Simon at TCB on
Acually I want to hear some reasoning from these super-human, altruistic contributors who simply code to serve the community without consideration of self-interest.

Answer me these questions.

If you are contributing out of the goodness of your heart then why does that goodness not extend to oracle? Why do you care which database it is, you are surely doing it for higher reasons? The good of the community. The WHOLE community.

What is it so difficult to support oracle? What are you doing, writing the whole PG version and the saying 'fuck, this will be hard to convert to oracle?'. Surely you should simply be doing both at the same time. Here's my little PG query, here's my oracle equivalent. You do have unit tests to prove they both work? Is this really massively time consuming or is it just that you're going about it the wrong way?

Have you thought about trying to automate the conversion to some degree? Why was that so difficult? Could no-one here have advised you?

Is there something fundamentally harder about oracle than PG? Surely the oracle folks here, who may not have time to contribute code, are not adversed to offering advice or guidance? I don't exactly see many 'how do you do this in oracle' questions? This implies to me you aren't even trying in the first place. Is this true?

I'm far from a database expert, but I can do a bit of oracle without too much trouble. Have you considered that perhaps the PG code you came up with in the first place is just piss poor and therefore you then find it hard to re-express in another database? Is this Oracles fault or are you making it harder than it needs to be.

If you can write it in PG, but are stuck when it comes to Oracle what does that tell you about your own ability? Should you really be commiting code in the first place?

I'd like to hear the answers.

Collapse
Posted by Don Baccus on
My estimate is that Oracle support adds about 50% overhead to the ongoing maintenance of a package. Less for new development.

We used an automated convertor when first porting ACS to the OpenACS dual-RDBMS support environment. For ongoing support, it's not as big a win as you might think because the tricky things can't be automatically translated. Anything that has to do with the tree structure of objects, in particular.

Now, at the same time we've been talking about dropping Oracle support, we've been moving more and more of the API into Tcl. Use of Tcl API makes support of Oracle easy during development.

BUT, as you well know, adequate testing takes time. Automated tests only take you so far.

There's also the administrative overhead of managing releases and the like.

Now, the current .LRN 2.2 release has gone well for both Oracle and PG. That's because we have ORACLE CONTRIBUTORS WILLING TO DIRTY THEIR HANDS ALONG WITH US INCOMPETENT "HOBBYISTS".

You guys step to the plate and help out, then Oracle support needn't end.

The dialogue over the past two years has taken the following form:

IF Oracle users don't step forward and contribute to Oracle support THEN we will probably drop it.

No one steps forward.

Repeat: IF Oracle users ...

No one steps forward.

OK, we'll drop Oracle support in, oh, a year or so, since no one cares enough to help support the platform.

SCREAMS OF PAIN AND ANGUISH! Oh Lord, we've stabbed you in the back!