Juergen Weber a écrit :
I think for a JDBC backend the actual database code should be trivial
in comparision with the database schema and mapping of LDAP queries to
SQL queries. Probably one would end with something quite similar to
the IBM paper
Mapping fitlters to SQL SELECTs might be tricky, for sure...
The structure of a RDBMS schema has been kind of overviewed a few months
ago :
http://cwiki.apache.org/confluence/display/DIRxSRVx11/Backend
But this is very initial thought...
(is that patented in the US?)
I have no idea ... I don't know if you can patent such trivial ideas ;)
Or a quite trivial mapping:
DNS: DN | EID
and
ENTRIES: EID | ATTNAME | ATTVAL
So ldapsearch -b "o=sevenSeas" "(givenName=William)"
would map to
select * from DNS D, ENTRIES E where D.EID = E.EID and D.EID like
'o=sevenSeas%'
and E.ATTNAME = 'givenName' and E.ATTVAL = 'William'
Remember that an attribute can have more than one value. Using a schema
where entry has three column can be seen as a waste of space, but it can
also be a waste of time has request will need to do 2 joints instead of one.
This is where we have a lot of things to analyze, test, evaluate. Just
consider that we might have more than one index per column. We have to
deal with six different kind of searches :
* present : an attribute is simply present, with a non null value)
* equal : the attribute value equals the assertion value, wrt matching
rule (that means we _must_ implement matching rules into the database.
Not so simple...
* approx : the attribute is an approximation of the assertion value
(soundex algorithm). How does it work for non european languages like
cantonese or hangul ?
* greater or equal, less or equal : we need to inject the comparators
into the database.
* substrings : equivalent to the LIKE SQL instruction
* extensible match : I don't know anybody using them, but anyway, it's
in the spec ...
All those guys are not easy to implement and are heavily relaying to the
Ldap Schema content. Not exactly a piece of cake to implement :)
One would have to see how efficient this join becomes for huge
directories ...
Well, not necessarily worst than doint in memory joins like we do with
our B-trees :) At least, RDBMS are very good at that, not to mention the
optimizations you can easily do with RDBMS help (Oracle has incredible
tools to analyze a request)
So far, the subject is damn interesting, but not as simple as we can
think at first glance. But I do think it worth the effort, definively.
Emmanuel.
PS : as this is pretty much Dev matter, what about switching to the dev
ML ? ([email protected])
