directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Directory Wiki] Update of "SubtreeRefinements" by CKoppelt
Date Sun, 04 Feb 2007 19:49:32 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Directory Wiki" for change notification.

The following page has been changed by CKoppelt:
http://wiki.apache.org/directory/SubtreeRefinements

------------------------------------------------------------------------------
+ deleted
- #format wiki
- #language en
  
- == Some Questions Answered ==
- 
- === What is it? ===
- 
- A subtree refinement is an optional component within a subtree specification.  It allows
the selection of entries within a specification based on the objectClass attributes of the
entry.  Hence if a subtree is defined and I have a refinement requiring all entries to be
inetOrgPersons then only those entries within the subtree specification will be selected for
inclusion in the subtree collection of entries.
- 
- More information about a subtree refinement as well as the entire subtree specification
syntax used by subentries is availabled here: [http://www.faqs.org/rfcs/rfc3672.html RFC 3672]
- 
- === Why is it needed? ===
- 
- A subtree refinement helps select out non-continous regions of subtrees based on the type
of object they are.
- 
- === What do they look like within the value of a subtreeSpecification attribute in a subentry?
===
- 
- Here are some examples of refinements whose definition is recursive according to [http://www.faqs.org/rfcs/rfc3672.html
RFC 3672]:
- 
- || '''Refinement'''                       || '''Equvalent Filter Expression''' ||
- || item:1.4.5.2                           || ( objectClass = 1.4.5.2 )         ||
- || item:person                            || ( objectClass = person )          ||
- || not:item:1.4.5.2                       || ( ! ( objectClass = 1.4.5.2 ) )   ||
- || and:{ :item:1.4.5.2, item:person }     || ( & ( objectClass = 1.4.5.2 ) ( objectClass
= person) ) ||
- ||  or:{ :item:1.4.5.2, item:person }     || ( | ( objectClass = 1.4.5.2 ) ( objectClass
= person) ) ||
- 
- Notice that there are no spaces between the tokens ''item'', ''and'', ''not'', ''or'', ''{''
on either sides of the colon '':''. There can be any number of spaces after the ''{'', after
the '','' and before the ''}''.  There can be no spaces before the comma ','.  
- 
- === How are you planing on evaluating Refinements? ===
- 
- Refinements are usually rare but they still need to execute rapidly.  The simplest approach
would be to represent a refinement as a filter expression leaving its evaluation up to the
search mechanism implemented by the backend.  Most often backends should optimize on rapidly
searching out entries based on objectClass ... meaning it would be foolish not to index this
frequently used search attribute.  Furthermore most of the time the question is whether or
not a single entry is accepted by the filter.  This is a cheap base scope search using the
filter.
- 
- We can easily use an antlr parser to build the filter expression tree every time the refinement
is pulled into memory.  All subentries and their contained elements should be available within
memory with optimized object representations loaded on initialization for rapid access.  The
subentries will be needed to make ACL, Schema, and other very important decisions.
- 

Mime
View raw message