Forum OpenACS Q&A: InterBase port interest

Request notifications

Collapse
Posted by Adam Farkas on
If you've been following the bboards over at ArsDigita, you'll see
that we are seriously considering working on an InterBase port.  We
have considerable InterBase experience in-house, but we want to
coordinate the port with the OpenACS developer community.

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.

Collapse
Posted by Guan Yang on
One.
Collapse
Posted by Lamar Owen on
I'll have to be honest, Adam.  I am most interested in the InterBas port in that, if it helps with easy (not trivial, of course, but not difficult either) cross-database portability, then I'm willing to do some work on it -- to help keep it running on PostgreSQL, as I have a vested interest in PostgreSQL.

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.

Collapse
Posted by Jimmie Houchin on
I am interested in the port to InterBase. I will also agree with Lamar. It would be very nice to see improvements which will allow it to be easier for other databases to be "ported" or used with ACS.

People have many reasons for their database choice. Lamar demonstrated this in his post. It would be great if ACS could be more accomodating of database choice.

One day even aD could be faced with this. Something comes along and supercedes Oracle 8i and aD wants to support past, current and future customers concurrently.

It would be nice for this to be done in such a way that there is only one ACS per se. Bug fixes to any port migrate up to the main ACS. Bug fixes to the main ACS trickle down to the ports.

This is an issue which hasn't been working as Don has been saying. It is one which will need to be addressed properly as ACS becomes multi-database. It has, it will. How it does it depends on aD.

There is an "OpenACS" simply because of the way aD has formerly done open source. Had aD been more accomodating of this, IMHO, I don't think the OpenACS people would have split off. I have hope that all of this can be worked out to everyone's mutual benefit and satisfaction.

Thanks.

Collapse
Posted by Don Baccus on
<blockquote><pre> Had aD been more accomodating of this, IMHO, I don't think
    the OpenACS people would have split off. </pre></blockquote>

Absolutely right, and we haven't really split off in that we've only forked the code in the sense of making the miminal changes necessary to support Postgres.  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.

Collapse
Posted by Don Baccus on
As far as help goes, I'm more than willing to help with the details of  database abstraction, including hacking through scripts making necessary changes.  My personal availability will be low from now 'til  October, though - I'll be spend 5-6 weeks out of town from mid-August 'til the end of September, most if not all of that time with no Internet access.

For many reasons I think that a move towards multi-database support should happen as 4.0 rolls out.  OpenACS has chosen to ignore 3.4 rather than port it, due to 4.0 looming on the horizon.  Hopefully folks can begin porting parts of the core technology that solidifies before 4.0, but a full port doesn't seem worth the effort since 4.0 will be such a huge rewrite.

Collapse
Posted by Roberto Mello on
I am willing to help too, but I don't want to ditch PostgreSQL. I want to help if it's going to help both DBs. PostgreSQL is a great product as well as Interbase, though I've never used Interbase so I don't know how heavy it is, etc...
Collapse
Posted by Adam Farkas on
Thanks for the replies, they've been enlightening.

I urge everyone who is interested in InterBase -- but has never tried it -- to go to www.interbase.com, download & install a copy. [just to see what i'm trying to get everyone into ;-) ]

InterBase is very lightweight and easy to install -- I downloaded it, installed it, fired up the client & started writing queries in under 10 minutes.  It also is very easy to administer.

Question, though, for the OpenACS experts [who have some familiarity with IB] -- do you think that an IB port could work within the common OpenACS source code tree?  Is it within the realm of possibility? [i'm asking for a realistic assessment..]  Or are the differences too big? thanks.

Collapse
Posted by Don Baccus on
Postgres is also very lightweight and easy to install.  If you're a RedHat user their installer will install it automatically when you build your system, or you can use their package manager to install it later.  Or you can install from source.  IB and PG are both so much simpler to install and administer compared to Oracle that quibbling about which of the two is actually the absolutely easiest is a quibble no shell-shocked veteran of Oracle installs and dba work will understand or care about.

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.

Collapse
Posted by Grzegorz Mucha on

I've worked with IB (though it was only my University Project, done on a 60-day trial version in April, May, connected to Web through PHP3 scripts - BTW why the hell ibase_*** functions in PHP3 documentation are only mentioned by name - FIY, at least they're similar to other ie. ODBC,MySQL or PGSQL functions).

Ibase is very user-friendly, I think more than PGSQL, it has some PL/SQL language, though it doesn't support such constructs:

SELECT name
     FROM (SELECT name FROM companies);

...Ok, I know it may not be a completely correct statement, but it was written on the fly....

One GREAT thing is possibility to define collation sequences - PG needs to be compiled to use locale - I'm Polish and we have those strange letters that need to be sorted.

That's all, an IB-port would be nice(I've seen one on the Web, but it was for the 4.x linux version - too old)

Collapse
Posted by Zavier Sheran on
I think before talking about porting to IB6 there should be a
thread-save driver for AOLServer 3.x available. Of course, strong
interest in the port could speed up development of such a driver,
but as a fact, it doesn''t exist yet (at least not publicly). I don't
know if I should choose AOLserver or Apache/PHP4 to use with
Interbase for a (hopefully) high-traffic site. A good part of the
decision will depend on the quality of the Interbase driver. PHP4
doesn't look bad, but it could be better. But there isn't broad
interest in IB from PHP users/developers and vice versa. PHP
folks seem to be sold on MySQL, which is a sad thing.
Collapse
Posted by Don Baccus on
Don't really need a threadsafe driver, as the external driver will work, just as is done with Solid and Sybase.  A threadsafe internal driver would be more efficient, but the penalty's not nearly as bad as  it used to be (the AOLserver gang tracked down a problem and were able to achieve a 10x speedup a few months ago).

So I would very much doubt that the driver would be a bottleneck other  than for the most high-volume sites.  AOL and Digital City successfully ran for years with the unfortunately slow previous version of the Sybase driver (and I'm sure run even better with the 10x faster version).  I think you're raising a bit of a red-herring.

As far as PHP, this project (OpenACS) is single-focused on the ACS.  General issues such as whether or not to use AOLserver+(Tcl? Python?) or Apache+PHP is are probably better addressed in the general AOLserver discussion forums at aolserver.com.  Among other things, the  AOLserver developers hang out there, not here, so you'll get more educated answers.

Collapse
Posted by Michael A. Cleverly on
Just for the record, the Solid driver is internal, not external. (One of the two MySQL AOLserver drivers is external, but Solid most definitely != MySQL! :-)