Steeg Carson wrote:
2011/1/6 Howard Chuhyc@symas.com:
Steeg Carson wrote:
2011/1/4 Quanah Gibson-Mountquanah@zimbra.com:
--On Tuesday, January 04, 2011 1:43 AM +0100 Steeg Carson steeg.carson@googlemail.com wrote:
I simulate this on my database just right now:
I suggest you read:
http://www.openldap.org/lists/openldap-technical/201011/msg00146.html
to understand how indices and their slots work.
As I now understand, the entire index for one attribute (e.g. objectClass) is "split" in several indexes. They holds for each path/node (resp. DN, but not leaf) an separate index for this attribute with all "hits" for his subtree (and for onelevel too).
No. Only the dn2id table maintains any notion of nodes and subtrees. All indices are global to the database and have no notion of scope.
But what does mean (from http://www.openldap.org/lists/openldap-technical/201011/msg00146.html):
"Ordinarily at each level of the tree we keep an index tallying all of the children beneath that point. In back-bdb this index is used for subtree searches and for onelevel searches."
So if I do a search, I'll get every time ALL results (ID's) from the index for the searched value. If my search uses additionally a searchbase the slapd takes all ID's and lookup in id2entry.bdb to get the DN for the ID and compare?
The search scope provides a set of candidates, consisting of every entry within that scope of the tree. An index lookup provides a set of candidates, consisting of every entry in the DB that matches the index. The intersection of these sets forms the set of candidate entries that must be examined in depth.
Can you recommend a good book, where I can read all such things and understand, how openldap really works? This are all very important things for design and operation.
There is no book on the internals of back-bdb or hdb. The source code is there for anyone to read. If you want to learn more, there are also extensive discussions on the design approaches and tradeoffs in the archives of the openldap-devel mailing list. For the most part, these discussions have only ever been of interest or relevance to other OpenLDAP developers.