jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timur Evdokimov" <ti...@jacum.com>
Subject Query language issues
Date Thu, 17 Feb 2005 18:32:52 GMT

Hello everyone,

I've noticed drastical changes in JCR query language(s), compared to what
used to be in JCR 0.15 
I feel somewhat uneasy about it.

First of all, my use case. There's a JCR-driven web site, filled with
various content. One part of it lives under /texts node, with rather complex
structure of sub-sections beneath. This part is regularly with new articles
being posted. On a home page, there must be a list of 20 recent articles
from _all sub-sections_ under /texts, in reverse chronological order, with
latest article on the top.

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
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?)

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?

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...

Any suggestions are greatly appreciated.

Best regards,

View raw message