Re: back-sql

[Dmitry Kovalev <mitya@seismic.geol.msu.ru>]

Hello, Robin!

Sorry for long delay, I was out for 10 days...

Now about ldap_entries...

The philosophy behind that is simple - it allows you to add hierarchy to your

RDBMS data... One must be able to arrange his data as LDAP TREE, not just all

entries below root entry... Having this table, you can map the same piece of
data into several entries located in any subtree...

Besides, it provides mapping between LDAP DN's and primary keys of
corresponding data ;)

Also, having this table added to the same tablespace as the data provides the

ability to express relations between RDBMS entities as LDAP attributes
containing DN of related object (see examples)...

All this at a rather small cost of having one more table... Also, if you
don't need any structure, you can simple write a trigger that adds a record
to ldap_entries whenever new record is inserted into your data table, and
deleting it when the data is being deleted...
Note that it has to be updated only in case of add,delete or rename
operations, which are not very frequent in common use of LDAP (or at least,
so they say ;) You don't have to update it upon update or search
operations...

Anyway, if you think of some general way to assign DN automatically (not only

with your schema), it is worth adding as alternative naming scheme - just
explain it.

Robin Elfrink wrote:

> Hi,
>
> Can anybody explain to me why the table 'ldap_entries' needs to be created
> when using back-sql? What's the philosofy behind that?
>
> I mean, why should I bother trying to get slapd working with my existing
> tablespace if I have to update "ldap_entries" with every change in my
> original data?
>
> I'd like to make back-sql behave so that my original database doesn't have
> to be touched in any way, but of course it'd be nice if I'd consult the
> original back-sql author(s) first, right?
>
> ---------- Have a nice day! ----------
> Robin Elfrink <robin@a1.nl>
> A3 Enschede B.V.