Forum OpenACS Q&A: InterBase port interest

I need to gauge how much interest developers here on the OpenACS side
of the fence would have in working on such a project.  We are
prepared to dedicate resources to the project -- including developers
experienced with InterBase -- to help with coordination and QA.

Please indicate your interest in helping with the project, either
here, or via e-mail. I just need to get a broad  sense of how many
people want to see this happen.  Thanks.

Having ArsDigita more and more interested in cross-database issues directly helps the PostgreSQL port -- and that _is_ what I'm running -- and InterBase's availability doesn't help there.  I have too many PostgreSQLisms in my own radio station's intranet system to easily switch.  Not to mention my own standing in the PostgreSQL developer community 😊.

But, this is not about the merits of IB versus PG versus Oracle -- this is about making ACS allow (if not encourage) more than just Oracle -- for that matter, more than just the three mentioned.  It should _not_ be as hard to port ACS to, say, DB2, as it was to get the port working in PostgreSQL.

As to the certain amount of anger, the old saw is that 'familiarity breeds contempt' -- unless the parties in familiarity work hard at avoiding contempt.

Had aD been more accomodating of this, IMHO, I don't think
the OpenACS people would have split off.

Absolutely right, and we haven't really split off in that we've only forked the code in the sense of making the minimal changes necessary to support PostgreSQL. We considered a deeper fork to implement modularization, etc but aD has stepped up to the plate with the package manager and other needed redesign and implementation of the core technology.

So, not forking is a goal of the OpenACS project.

I'm extremely supportive of aD's wanting to support IB if doing so pushes aD into implementing data abstraction to the extent that a single source tree can support multiple databases.

Doing so would almost bring OpenACS to an end in the sense that the maintenance and porting job would be much, much simpler than it is today. Who can argue against this?

Of course, it is a pity that suggestions that aD work to make it much simpler to support a second RDBMS engine were explicitly rejected in the past. I realize that aD's openess to the notion of supporting IB as well as Oracle is due to new folks who are on board who perhaps aren't quite so entranced with the notion that Oracle is the only RDBMS worth using. In other words, it is a matter of timing. New people have come aboard with new notions of what aD should do with the ACS, and that's a good thing.

What would really be great would be if aD would make a commitment to supporting not only IB, but PG. The thousand folks who've downloaded OpenACS are certainly an indication that there are a lot of people interested in ACS/pg. I don't see any particular reason to believe that IB is significantly superior to PG, if it is superior at all. Certainly in the feature department IB and PG are comparable, with IB ahead in some areas (most notably outer joins and a storage manager that reclaims space without the need to "vacuum"), PG in others (greater Oracle compatibility). In terms of performance they're probably both comparable under real load, and they share virtually identical row-level locking algorithms, making each much better in high-concurrency situations than (say) MS-SQL.

So when we've kicked around the idea of supporting IB as part of the OpenACS project, it hasn't been in the context of dropping PG support. It has been in the context of building in data abstraction so that we could support BOTH RDBMS systems from a single source tree.

There are four reasons we've not tried to put together a project thus far:

1. IB hadn't yet released their "super server" in Open Source.

2. Doing database abstraction to the level we'd discussed would commit us to a fork from ACS Classic sources, something we've been loath to do until 4.0 (it would require a fork because historically aD's been cold to the idea of modifying ACS Classic in such a way, as I mentioned above).

3. Limited resources - we're doing this without compensation which means we do it in our spare time.

4. PG has worked a lot better than some folks thought it might, which has probably lowered the enthusiasm for doing the work a bit.

Now, if aD is to support IB, it would be idiocy to do so with a second source tree rather than rework the core technology in order to abstract out queries. If this work's going to get done, it is certainly doable in such a way as to make supporting PG out of the same tree very practical.

If it is impractical to support a single source tree for Oracle & IB due to aD's business needs, then Sebastian should really be working within the OpenACS project so we can at least support PG and IB from a single source tree. This implies a fork, yes, but only into two rather than three trees. Sub-optimal, but not worst case.

As far as supporting Oracle, IB and PG out of a single code tree, it would be a major undertaking.  Specifics regarding PG have been discussed before, and I think Ben's even got something written up somewhere that outlines steps that could be taken.

If queries were split from scripts, all ADP and Tcl scripts could be shared.  On the other hand, there's an admitted cost in maintainability and readability in doing such a split, which means it isn't really in aD's interest unless they intend to actively and agressively support IB (which in your business model I presume would mean chasing down web-development business using IB rather than Oracle  as the underlying RDBMS).

The scheme to name queries is a compromise that is a bit ugly but helps a lot.  In addition, simple abstractions like "how many days old  is this table entry?" would serve to isolate differences to a single Tcl proc.  This means the IB or PG porting grunt wouldn't have to ferret out each and every query that asks this question, and port it.

Simple things like this would help a LOT.  I'm certain Ben's passed on  specifics regarding PG to aD in the past.

The new db_* database API will inadvertently help us, because all queries will pass through it, allowing us to regexp queries to mask some differences (we already do this to some degree).  This new API is particularly important due to all queries being changed to use "ns_ora" and bind vars rather than generic "ns_db" calls.  We plan to think long and hard about inventing ways to translate Oracle queries to their Postgres equivalent within the db_* API layer, in order to minimize the number of changes to Tcl and ADP scripts.

The more we can do this, the more we can use "patch" to upgrade to successive ACS versions - minor update versions, at least.

Sebastian indicated he would be working on a list of IB features/shortcomings etc that would impact a port.  I assume he'll include the need to deal with SQLJ, Intermedia etc.  It would really be useful if Sebastian were to complete a comprehensive list of stuff he knows are different in the IB and Oracle SQL dialects, and post them here for our education.  We could then take a look at the needs of all three databases and start thinking about a strategy for reducing the maintenance load as much as we can given the fact that aD's interest in this is (currently) minimal.