[
https://issues.apache.org/jira/browse/JCR-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753636#action_12753636
]
Alexander Klimetschek commented on JCR-2302:
--------------------------------------------
That one looks better and is the same as (2) for all elements I can see. I
would suggest to make the parser for the order by clause more flexible and
allow all variants:
@jcr:content/cq:lastModified
jcr:content/@cq:lastModified
jcr:content/cq:lastModified
However, doing an ascending search still produces different results. IIUC,
these two queries should yield the same result, only looking at nodes with
actual cq:lastModified properties present:
(a) //element(*, cq:Page)[jcr:content/@cq:lastModified] order by
jcr:content/@cq:lastModified
(b) //element(*, cq:PageContent)[...@cq:lastModified] order by @cq:lastModified
The results are similar, ie. the second element is the same, but notably the
first element shown in (a) is not present in (b). In this case it looks like
(a) (the one with the child axis order by) is the correct result this time.
> Child axis support in order by clause does not work
> ---------------------------------------------------
>
> Key: JCR-2302
> URL: https://issues.apache.org/jira/browse/JCR-2302
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, jackrabbit-spi-commons, xpath
> Affects Versions: 2.0-alpha9
> Reporter: Alexander Klimetschek
> Priority: Minor
>
> Child axis support for order by in xpath queries was introduced with JCR-800.
> In my use case I have a cq:Page nodetype which has a jcr:content child of
> type cq:PageContent (like nt:file and nt:resource). The jcr:content child has
> a cq:lastModified time stamp that I want to search on. I use descending to
> see the most recently modified nodes at the top.
> The problem is that it does not work when using a child axis in the order by:
> (1) //element(*, cq:Page) order by @jcr:content/cq:lastModified descending
> This gives a different (and wrong) result compared to the simpler query on
> level deeper, which returns the correct results:
> (2) //element(*, cq:PageContent) order by @cq:lastModified descending
> Switching between ascending and descending in (1) does not change the result
> set at all, ie. the order stays the same.
> A reason could be non-existing properties (of which there are some in my
> data), so to only look at existing properties, I run this query, which still
> gives incorrect results:
> (3) //element(*, cq:Page)[jcr:content/@cq:lastModified] order by
> @jcr:content/cq:lastModified descending
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
