jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: Query language issues
Date Fri, 18 Feb 2005 08:39:18 GMT
Hi Timur,

Timur Evdokimov wrote:
> Before, I've been able to write something like
> SELECT * FROM my:article LOCATION /texts//* WHERE
> my:includeInMainStream='true' ORDER BY my:publishingDate DESCENDING
> and select 20 latest nodes from NodeIterator
> Now, in 0.16, it seems like it's more like standard SQL without LOCATION
> clause
> So I can't say LOCATION /texts//* anymore, and forced to do something like
> jcr:path LIKE '/texts/%' which yields only direct children of /texts, but
> not their descendants! And (jcr:path LIKE '/texts/%') OR (jcr:path LIKE
> '/texts/%/%')  OR (jcr:path LIKE '/texts/%/%/%') could possibly work (though
> it looks somewhat stupid) but it doesn't work at all (bug in RI?)

Yes, that's definitively a bug in jackrabbit. jcr:path LIKE '/texts/%' 
should select descendants of /text and not just its children.
I've created a JIRA issue: http://issues.apache.org/jira/browse/JCR-49

> Another option seem to be XPath query with
> /texts//*[@my:includeInMainStream='true']... but then I'd lose my rather
> important ORDER BY my:publishingDate!
> Pardon my ignorance, maybe there's better way to write this query?

The XPath variant JSR-170 uses, allows you to specify an order by 
clause. So, you can write:
/texts//*[@my:includeInMainStream='true'] order by @my:publishingDate 

> And I don't feel quite like that jcr:path LIKE xxxxxx thing is something
> that deserves to be there. 
> Maybe it should be at least allowed to be something like jcr:path LIKE
> jcrf:xpath('/texts//*'), or I don't know what...

yes, that would be another way. The goal was not to introduce too many 
new constructs, but use what standard SQL provides. Either way has its 
pros and cons...


View raw message