Forum OpenACS Development: Re: Re: OACS 6 and beyond (database abstraction layer)
The two aren't comparable.
Now 10g's relaxation of restrictions on CONNECT BY queries actually helps a bit (because you can join tables against CONNECT BY subqueries) ... I can actually visualize being able to build similar queries for both schemes via subqueries and joins against them ... but they wouldn't scale well. Scaling tree-building queries using the two models requires different strategies.
We've talked about tcl-based table declarations of the sort Neophytos talks about in his xotcl stuff.
The problem is that we need to clean up the somewhat conflicting attribute systems in the content repository and that for base objects.
Lots of datamodel clean-up.
WITH LOTS OF UPGRADE SCRIPTS.
This grunt-level work would need doing for both databases, and of course would need to be EXTREMELY well-tested in both environments. With realistic data representative of real sites.
The need to provide an upgrade path is a (NECESSARY) millstone around the neck of those that would like to clean-up the datamodel as a first step towards making a much cleaner and easier development environment for programmers.
The need to provide upgrade paths for two databases is a double-weight millstone. Worse, actually, because as is pointed out, I've been the only person committed to keeping Oracle supported.
In short, the higher-level API path (exposing as much as possible through Tcl API as we've been increasingly doing the past couple years making it easy to write db-independent code, or an Xotcl approach such as Neophytos favors) helps the easy problem.
Unfortunately, if that were the only problem, Oracle wouldn't be a big deal.
But fundamental clean-up of the datamodel combined with upgrade scripts is a much harder problem, and eye-candy help such as higher level APIs for the easy part of the problem isn't all that beneficial.
On CONNECT BY: Rails implements nested sets and trees on top of either of the three databases -- Oracle, PG, MySQL. Maybe there are a few lessons that could be learnt from it.
There does seem to be some performance impact in doing it the way Rails does, but having Tcl inside of AOLServer may just as well neutralize it, don't you think?
If you're suggesting that Rails does the nested tree support in the Ruby layer, I'd humbly suggest that this is likely to be terribly inefficient if sizable trees are involved.
I should also point out that the forums package's oracle version uses tree_sortkeys rather than CONNECT BY queries.
And that PG in the semi-near future should support SQL's recursive queries that would allow an approach similar to CONNECT BY.
I am not an active participant nor a frequent user of openACS. But after going thorught this long forum postings, I have a question.
Can someone tellme what exactly is the reasons of dropping the oracle support? It would be good if we know exactly the work/effort required then we can collective divide the work and start supporting openACS with oracle.
1. Is it because of lack of Oracle users in the community who will test oracle code and give green signal to it?
2. Since Don is the only person doing this and he is not interested in doing and no one is there to take that responsiblity. So we are dropping oracle support?
3. Or is it because of licensing issues of oracle?
What exactly are the reasons of dropping oracle support? We know that upto now openACS was suppporting both databases and most of the websites are running on openACS having backend both oracle and postgres. Can someone (Malte, Don or Dave) please actually list down the things that is required to support oracle with openACS 6
I see most of them had shown anger/disrespct to other users but again its not directly from the heart but its more about the frustration of not having oracle support.
Why dont we actually know the things that is required in order to continuing support oracle?
I will be waiting for the answers then..
1. Yes Oracle maybe dropped in the future if no one will step up in testing it.
2. Currently its only Don who does the testing, its difficult and not a sustainable model as Don is not really doing Oracle development
3. Its not a licensing issue, its a manpower issue.
I hope a member for the OCT can confirm my answers.