Re: back-sql auxiliary class support and more

["Pierangelo Masarati" <ando@sys-net.it>]

>
> Hello, during the last week I worked on the following issue:
>
> 1. a perl script thaht generate sql tables, functions to insert and
> delete ocs  and attrs based upon a given LDAP schema (I tested it with
> all openLDAP  schema + SaMBa 3)

If you mean the meta-info tables that are required by back-sql,
that's fine; if you mean the tables that contain the data,
you're actually likely to be defeating the purpose of back-sql.

back-sql is intended to provide a mapping, or a view, of existing
data in a RDBMS in LDAP format.  Apparently, you're working at the
opposite, that is create RDBMS data from an LDAP schema.

I don't question the opportunity to do this (it's already ben
addressed by other people, though
http://www.openldap.org/faq/data/cache/378.html ) but it may
have little to do with back-sql.

>
> 2. patches to allow the back-sql handle correcly auxiliary classes.

This might be interesting.  There is already a means to handle
more than one objectClass in an entry, but I'm not comfy with it
because it's done on an entry's base, and cannot be extended to
sets of entries based on logical rules.  Note that this part
of back-sql has been recently updated in HEAD and REL_2_2 to
allow more instances of an attribute type in an entry, plus other
improvements; make sure you're patching HEAD code, otherwise patch
inclusion would require a much larger effort.

>
> 3. a full working example
>
> Actually the patches are in a prototype state (there is a query that
> have to  be inserted in the config) and I don't know if -even if they do
> work- is  "correct" from the point of view of the place where I put the
> procedures and  whatever (say from thepoint of view of the development
> guidelines).
>
> QUESTION: Should I submit the patches as indicated in the guidelines or
> is it  better to post them here so that someone can check the
> correctness and then  after a revision and whatever post a patch ?

I strongly suggest you open an ITS so that we can keep track
of the state of your issue; I'd also suggest that you submit
a what you consider a FINAL patch, so that the impact of its
import is minimal.  The patch will be reviewed, of course,
but I'd prefer that you review it yourself, first.

> BTW: also I would like to go on contributing within the back-sql work.

contributions are always welcome, as soon as they lead
to changes/improvments that are of general use.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it