Re: jcr:deref doesn't maintain order of multi-valued REFERENCE property

[avim <av...@timetoknow.org>]

mmm... here is the case:
Many to many relations are represented by multi-valued REFERENCE properties
and as mentioned the order is crucial. The typical query is:
//*[@prop1='value1']/jcr:deref(@references,'*')[@prop2='value2' or
@prop2='value3']
The q is how do I something like that without jcr:deref?
How do I configure/disable document order behaviour? will it help?
Any best practices for JCR "connection objects" like connection tables in
RDBMS?

Thx
Avi



Marcel Reutegger wrote:
> 
> avim wrote:
>> The order of (values of) multi-valued REFERENCE properties IS maintained
>> by
>> the repository(as specified in the spec).
>> However, jcr:deref doesn't respect that order.
>> It seems that it's affected by the saving order of the referenced
>> nodes!?!
>> Is it a bug?
> 
> no, it's not a bug. the jcr:deref() function does not have an inherent
> ordering. 
>   the final query result however has a defined order. per default the the
> order 
> of the nodes in the query result are in document order similar to XML
> (see: 
> http://www.w3.org/TR/xpath#dt-document-order). this behaviour can be
> disable in 
> the configuration of jackrabbit to achieve better query performance. then
> of 
> course you can use explicit ordering on given properties. e.g.
> 
> //element(*, nt:file) order by @jcr:created ascending
> 
> or let the implementation decide which node matched best:
> 
> //element(*, nt:file)[jcr:contains(jcr:content, 'jcr')] order by
> jcr:score() 
> descending
> 
> regards
>   marcel
> 
> 

-- 
View this message in context: http://www.nabble.com/jcr%3Aderef-doesn%27t-maintain-order-of-multi-valued-REFERENCE-property-tf3081154.html#a8805846
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.