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
|