SQL Backend

[Predrag Balorda <pele@artewisdom.com>]

Sorry for the long-ish post...I hope you'll have time to read it.

Ok, well seems _again_ a few misconceptions have arisen.
Let's clear up some things here.

First, Kurt is the nearest to my thoughts on proper RDBMS support in
lib-ldbm. What we are talking about here is modifying lib-ldbm to not
only support the three or so interfaces it does currently (dbm, ndb,
gdb, db2..) but also to include support for a proper RDBMS. You can even
do an OODBMS but I don't know much about that stuff. Now, the goal is to
support as many as possible, so people can store their database on an
Oracle 7/8/whatnot, Sybase, Ingres, Postgres, Postgres95, PostgreSQL,
mSQL, mySQL, miniSQL, db2 on an as400 and all sorts of other wonderful
RDBMSes floating around. That's sorted now.

Other thing, in order to support them all you have to do one of the two
things:
Either, support each and every one of them, and be stupid,
or
find the lowest common denominator among them and support that. ODBC
springs to mind.
So, concentrate the effort around writing ODBC support into the lib=ldbm
and that way support many RDBMSes who have ODBC drivers available for
them. Others who have a RDBMS _without_ any ODBC support/drivers should
be catered for by someone writing backend-specific lib-ldbm interfaces.

Third, tih wrote to warn us that ODBC spec says you have to have ODBC
drivers on the client. Which is true. But what is also true is that this
time our LDAP server is a client, a middle tier in a three-tier
architecture. So, your LDAP client asks our LDAP server something, and
then our LDAP server asks the RDBMS through the ODBC manager. So that's
now sorted aswell.

Fourth, please do not mix SQL and Python/Tcl/Perl/C/Java whatever.
This is the wrong thread for that. This is about an SQL Backend for
OpenLDAP server and not a general discussion on which language is nicer.
BTW, SQL is a query language, not a programming language.

Fifth, to answer Kurt's question - think a bit. It would be a bit silly
to write a daemon sitting in the background waiting for connections from
the LDAP server just to pass on the connection to the ODBC manager which
in turn passes it on to the RDBMS you want to use. That's 3 hops. Why
not have 2 instead, by way of having a direct link from lib-ldbm to the
ODBC manager which then takes care of the remaining hop to the RDBMS.
AND! And, you still _can_ specify which database you want your directory
to be fetched from or stored in, remember slapd.conf? well, I suppose we
could add something like:

database	ldbm
suffix		"o=Pele Pele Ltd, c=MARS"
directory	odbc:postgresql:peles_employee_eb pele mysecretp
rootdn		"cn=pele, o=Pele Pele Ltd, c=MARS"
rootpw		mysecretp
database	ldbm
suffix		"o=Happy People Ltd, c=VENUS"
directory	file:/usr/local/ldap/var/data
rootdn		"cn=joey, o=Happy People Ltd, c=VENUS"
rootpw		hissecretpw

and so on.
So, notice the URL-awareness of this future OpenLDAP server. Cute or
what? Roll with the times...
AND AND there's also another possibility - no flames on this one please.
Scince the Java 1.2 spec allows for application to easilly "embed" a
java interpreter, it is also possible to load a jdbc-compliant class
that actually handles all jdbc connections (and nowdays many RDBMSes
have jdbc drivers) to database backends. This solution would be a doddle
to write, scince Sun's specifications nowdays really are a breeze to
use. But that's a different story, because then JNDI comes to mind and I
have so many things to worry about this week allready.
So, there you have it. Thoughts again...

Pele