[
https://issues.apache.org/jira/browse/JCR-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753682#action_12753682
]
Alexander Klimetschek commented on JCR-2302:
--------------------------------------------
> I'd rather make it more strict ;) and only allow the second (and maybe the
> third)
I already adapted my code for it. I was just suggesting this, because there are
some places where child axis are possible (xpath predicates and jcr:contains,
jcr:like functions) and not all are restrictive. A strict @ should only be
required if it is necessary to separate nodes and properties, but for orderby,
only properties are possible anyway, so I wouldn't be that strict. And if it is
strict, there should be an InvalidQueryException for the "wrong" cases, IMHO.
> - the result sizes may be different because some of the jcr:content nodes are
> not of type cq:PageContent
Oh, I thought I checked it... for the first element that occurred wrong this
was indeed the case, being of nt:unstructured.
> last modified values may be the same on multiple result nodes. in that case
> the ordering is not defined and is implementation specific
It would be useful if it always follows the same order in that case (also for
multiple executions of the same query), so that components that automatically
show you the latest content by running a query every 20 seconds or so have a
stable result.
> 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.
