Re: back-sql - uniqueness constraint in ldap_entries

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

Hello Peter.

Peter Duffy wrote:

> Hi,
>
> I'm trying to build a mysql database based on an existing ldbm backend.

Didn't catch you at all... ldbm backend has nothing to do with sql, and
mysql in particular...

>
> In the sample file "backsql_create.sql" for mysql (in
> servers/slapd/back-sql/rdbms_depend), after the basic setup of the table
> ldap_entries, there's an extra uniqueness constraint defined for the
> combination of columns oc_map_id and keyval. As I understand it,
> oc_map_id references ldap_oc_mappings, and keyval references whatever
> table the row in ldap_oc_mappings points to.

exactly.

>
> I'm hitting a problem in that the RDN "dc=net" is used at different
> levels of our LDAP tree (some entries have two domain components, some
> have three or more.) This produces at least one case where the above
> uniqueness constraint is violated (same values for oc_map_id and keyval
> in >1 rows,) yet the LDAP tree is valid (the DN resulting from the
> sequence of RDNs is unique.)

don't see how this problem relates to RDN "dc=net", because ldap_entries is
intended to store DNs, not RDNs, so you get unique entries.
I'd say that it arises when you want some data (pointed by one keyval) to
be presented as several LDAP entries, identical except for their DNs...

for instance, you have one recordset for a person in RDBMS, but want
corresponding object to be under ou=People, and under some other node...
Since alias objects are not supported yet, you can use such trick.
In fact, I didn't implemented aliases at once because of this possibility.

BTW, referrals and multiple objectclasses (not to confuse with objectclass
mapping, which has to be unique) needed for them are supported.


>
> The obvious way out of this is simply to leave out the uniqueness
> constraint: my concern is whether or not this would actually break the
> SQL backend code, or leave the resulting directory open to spurious
> updates and resultant damage. If anyone has any input on this, I'd be
> most grateful: by default, I'll probably suck it and see!

this will do no harm. the reason for this constraint was to have ability to
present relations between your relational entities as attributes with
related DNs (this must be somewhere in examples, and it turns to require
such a constraint). but if you don't need such things, you can safely wipe
out this constraint.

WBW, Dmitry