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 ? (dev@directory.apache.org)
|