Hi Jörg,
first, I have to told you we didn't received any news from incubator for
your code submission. I will try to ping incubator again to see if
someting is stalling for a reason or if we have missed some step (I just
suscribed to the incubator PMC today, I should have done it sooner, but
I think I just forgot to do so and thought I already did it. My bad).
Back to the thread now :)
Jörg Henne wrote:
Emmanuel Lecharny schrieb:
Any other solution in mind ?
not having done any work on the backend makes it impossible for me to
make well-founded comments on the issue. However, the recent
discussion around splay trees and the problems with the current JDBM
layer got me thinking that the requirements of the database layer are
almost entirely identical to those of the RDBMS:
- entries are reasonably similar to tuples
there is a big difference between entries (ldap) and data in a RDBMS :
entries are multivalued. This make it more complex to manage such data
efficiently in a database, but not impossible. In any case, this is
possible.
- all indexes are essentially secondary indexes
- DNs are are similar to a primary key, but may also be treated like a
secondary one.
Some not-so-lateral thinking brings up the question of whether it is
really necessary to invent another wheel.
We don't want to reinvent the wheel, but to select the most appropriate
kind of storage to get the most performance out of the server. When it
comes to search, you have a three step approach which work :
- if you have less than a thousand elements, just use a list in memory
- under a few hundred of thousands elements, a hashmap is better, for
non ordered data
- above one million, BTree will be better, just because you won't be
able to cache everything.
The idea may be totally silly, and the required effort may easily make
the think not worthwhile, but what about having a look at Derby's
store layer:
http://wiki.apache.org/db-derby/StoreLayerLinks
and in particular http://db.apache.org/derby/papers/btree_package.html
We have to check this. But switching from JDBM to Derby BTree might be
way too costly compared to the small modification I want to introduce
into JDBM code base.
Let's say that what I want to do is to workaround a bigger problem until
Alex has finished his cursors implementation. Then we will be able to
think about decoupling ADS from JDBM and analyze some alternative like
Derby BTree.
At some point, we really want Derby, Postgresql, LDIF, etc to be storage
for ADS, like what OpenLdap supports :
bdb Berkeley DB transactional backend
config Slapd configuration backend
dnssrv DNS SRV backend
hdb Hierarchical variant of bdb backend
ldap Lightweight Directory Access Protocol (Proxy) backend
ldif Lightweight Data Interchange Format backend
meta Meta Directory backend
monitor Monitor backend
passwd Provides read-only access to /passwd/(5)
perl Perl Programmable backend
shell Shell (extern program) backend
sql SQL Programmable backend
Thanks for the heads up, Jörg !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
