Emmanuel Lecharny schrieb:
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).
No worries!
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.Without knowing the Derby database layer in detail, this is just a wild guess, but it may be possible that from a storage perspective (not the indexing perspective, of course) tuples are treated as black boxes, which would lessen the difference between tuples and entries. However, with large numbers of attribute values it might still be necessary to normalize them, as it is currently done.
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 :Hashtables may be justified in some cases, however, the break down for range- and partial searches. Quite a few DBMS implementations therefore don't use them at all, since it turns out that a well-managed B+-Tree is "good enough" even if one does a lot of single-value primary-key accesses like in the case of a join.- 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.
At some point, we really want Derby, Postgresql, LDIF, etc to be storage for ADS, like what OpenLdap supports :I totally agree - the ADS storage layer API should accomodate a range of possible backend implementations and therefore be as implementation-agnostic as possible.
Joerg Henne
smime.p7s
Description: S/MIME Cryptographic Signature
