Marcel Reutegger wrote:
I'd like to keep a move operation cheap but I also agree that
hierarchical query operations need to be improved.
Same here. Making move operations expensive is a very high price for getting
fast queries. Although I'm not sure how common the usecase of moving big
subtrees is?
we should definitively try to execute such queries in a reasonable time.
I think this is a very common use case. can you please create a jira
issue? I'm not sure if the hierarchy is the issue here or just the fact
that lots of nodes need to be ordered. do you have more insight on this?
Ordering should be ok since we resolved JCR-974. Although it would still be nice
to have a less memory intensive solution (all FieldCaches are hold in memory).
Obviously, this only works when I index a node's path in some lucene
field. So a node with path /documents/en/news/2007/10/14/item.xml
would have lucene Field that contains the terms
'/documents/en/news/2007/10/14/item.xml'
'/documents/en/news/2007/10/14'
'/documents/en/news/2007/10'
'/documents/en/news/2007'
'/documents/en/news'
'/documents/en'
'/documents'
maybe this approach can be turned into a clever hierarchical cache?
without the need to index the whole path with a node.
My hope is that we find exactly that kind of clever cache ;) I even think we
should make this one persistent because you have to read every node to build it
and I think it might consume to much memory for big repositories (at least if we
keep the paths human readable like above).
Maybe I have some time on Friday to think about it. But maybe Ard is faster to
come up with a solution ;))
Cheers,
Christoph
