You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Ard Schrijvers <a....@onehippo.com> on 2010/05/25 11:51:31 UTC

Re: Descendant nodes properties

2010/5/20 François Cassistat <f...@maya-systems.com>:
> Hi,
>
> is it possible to configure indexation so path-based properties tests gets faster in a similar way aggregate is used for full-text search?

You have some indexing_configuration.xml where you can define some
indexing rules, but queries like: 'where there is a child node that
has propA=valA' are not possible to index more efficient. It also make
sense that it is hard to do this in a general jcr repository: If you
can query fast on properties of child nodes, you should also be able
to query fast on properties of child nodes 5 levels deeper.

But, if you have a very clear content model, you might want to hook in
your extended indexer capable of indexing child node properties on,
say, your notion of a 'Document'. This is however far from trivial,

Regards Ard

>
>
> Frank
>
>

Re: Descendant nodes properties

Posted by Ard Schrijvers <a....@onehippo.com>.
2010/5/26 François Cassistat <f...@maya-systems.com>:
> This would be a nice feature. I should have a look into Jackrabbit indexer code, but time is missing.
>
> But you gave me another idea, maybe I should simulate indexation by copying values into the parent's node into a special pre-defined property. It makes me change writing procedures and queries, but should speed up the search operations.

Yes, this is how I normally advice the content model to be: properties
you want to sort and query on, try to have them on the nodes you want
to find in a search

Ard

>
>
> Thank you,
>
>
> Frank
>
>
>
> Le 2010-05-25 à 5:51 AM, Ard Schrijvers a écrit :
>
>> 2010/5/20 François Cassistat <f...@maya-systems.com>:
>>> Hi,
>>>
>>> is it possible to configure indexation so path-based properties tests gets faster in a similar way aggregate is used for full-text search?
>>
>> You have some indexing_configuration.xml where you can define some
>> indexing rules, but queries like: 'where there is a child node that
>> has propA=valA' are not possible to index more efficient. It also make
>> sense that it is hard to do this in a general jcr repository: If you
>> can query fast on properties of child nodes, you should also be able
>> to query fast on properties of child nodes 5 levels deeper.
>>
>> But, if you have a very clear content model, you might want to hook in
>> your extended indexer capable of indexing child node properties on,
>> say, your notion of a 'Document'. This is however far from trivial,
>>
>> Regards Ard
>>
>>>
>>>
>>> Frank
>>>
>>>
>
>

Re: Descendant nodes properties

Posted by François Cassistat <f...@maya-systems.com>.
This would be a nice feature. I should have a look into Jackrabbit indexer code, but time is missing.

But you gave me another idea, maybe I should simulate indexation by copying values into the parent's node into a special pre-defined property. It makes me change writing procedures and queries, but should speed up the search operations.


Thank you,


Frank



Le 2010-05-25 à 5:51 AM, Ard Schrijvers a écrit :

> 2010/5/20 François Cassistat <f...@maya-systems.com>:
>> Hi,
>> 
>> is it possible to configure indexation so path-based properties tests gets faster in a similar way aggregate is used for full-text search?
> 
> You have some indexing_configuration.xml where you can define some
> indexing rules, but queries like: 'where there is a child node that
> has propA=valA' are not possible to index more efficient. It also make
> sense that it is hard to do this in a general jcr repository: If you
> can query fast on properties of child nodes, you should also be able
> to query fast on properties of child nodes 5 levels deeper.
> 
> But, if you have a very clear content model, you might want to hook in
> your extended indexer capable of indexing child node properties on,
> say, your notion of a 'Document'. This is however far from trivial,
> 
> Regards Ard
> 
>> 
>> 
>> Frank
>> 
>>