jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Pickering <benpicker...@gmail.com>
Subject Re: Query language issues
Date Fri, 18 Feb 2005 09:45:31 GMT
I think it would be nice to have the path expressions as first-class
constructs in the syntax, even if this does involve moving away from
the SQL syntax...

After all, it is a tree rather than a database being queried.

-- 
Cheers,
Ben


On Fri, 18 Feb 2005 09:39:18 +0100, Marcel Reutegger
<marcel.reutegger@gmx.net> wrote:
> 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
> descending
> 
> > 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...
> 
> regards
>   marcel
>

Mime
View raw message