Re: back-sql

["Dmitry Kovalev" <mityak@iname.com>]

Hello Dirk!

----- Original Message -----
From: "Dirk Vleugels" <dvl@de.uu.net>
To: <mityak@iname.com>
Sent: Wednesday, March 29, 2000 2:58 PM
Subject: back-sql


>
> Hello Dmitry,
>
> i was able to built openldap-head with your back-sql module enabled
> (using mysql & iodbc on debian-linux 2.2). Everything works as
> expected (using the testdata).
>
that's cool. if you have any suggestions on documentation (and/or code),
please mail...

> One question remains though: Will it be possible to generate
> replication logs for slurpd when doing updates/add/delete against the
> rdbms tables? I can't see a solution so far (maybe oracle external
> procs?) , and LDAP without replication is a 'no no' for the operations
> people i fear...

Principally, there should be no problem with using standard replication,
because back-sql now supports write operations (on databases with stored
procedures, such as Oracle or MS SQL Server). It just means that you must
make your changes through LDAP, not directly in RDBMS. I personally had no
need in replication so long, so I haven't tried this, but everything must be
fine. Please mail if you try such scheme.

Real cases where your problem may arise are when your RDBMS does not support
stored procedures, and thus back-sql becomes readonly, or when you HAVE to
make your changes through RDBMS, not LDAP.

For first case I have some modifications in "to do", which would make
back-sql more relaxed about passing parameters for
modification statements. For now it expects such statements to be procedures
with fixed interface (id first, then data). I'm going to change this somehow
to allow use of common "insert" statements (which requires "data then id"
parameter sequence as minimum). It could help to implement write support
without stored procedures in many cases, and use standard replication. I
will provide samples for mySQL write support when I implement this.

In latter case, the only way I can think about for now is the one you
mentioned - triggers writing out replication log. But it is hard to provide
some general solution for this, as with write support procedures, because
they are schema-specific. Maximum I can do is provide such things in my
sample sometime later...

All this is not very clear to me, so I cc this to  devel maillist for
possible comments...

WBW, Dmitry