David Johnson wrote:
While I can see how my suggested optimization could severely impact some
use
cases. Nevertheless, "our use case" :-) is mostly querying a stable
hierarchy structure - i.e., we rarely, if ever, would move a tree with even
1000s of sub-nodes (famous last words). And we use the node hierarchy in
our queries --- well, always!
The balance between use cases is suggesting to me the need for
administratively defined indexes that could be used by the query processing
engine if they existed. So that users (repository administrators) could
define the indexes - like this one - with the knowledge that certain
operations (a move) would require a fairly expensive rebuild of the
indexing
structures.
Could you give some more detail on how ChildAxisQuery and
DescendantSelfAxisQuery work. On first read, the comment at the beginning
were not completely clear to me - more than likely related to me. I
think I
get what they are doing, I just would like a little more overview, to help
me before jumping in and attempting to understand the code. It seems that
the query parser breaks down a path into its pieces, and this is then fed
into the LuceneQueryParser as location steps - and these get changed into
ChildAxisQuery or DescendantSelfAxisQuery as appropriate?
that's correct. both queries have a context query. the matches of the context
query is then used as a starting point to 'calculate' the child nodes or
descendant-or-self nodes.
regards
marcel
