jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timur Evdokimov" <ti...@jacum.com>
Subject RE: Query language issues
Date Fri, 18 Feb 2005 22:59:48 GMT

Hi Marcel,

With latest SVN update of today, everything seem to work with SQL.

But Xpath still doesn't work as it should

In //*[@my:includeInMainStream='true'] order by @my:publishingDate
descending
It complains about @ in @my:publishingDate clause
So that only order by publishingDate is accepted, but doesn't work anyway

Also any expression apart from //* returns nothing, i.e. just /text//* gives
0 hits, whereas 
SELECT * FROM my:article WHERE jcr:path LIKE '/text/%' gives what it
supposed to give.

Am I doing something wrong or Xpath is just not polished enough there?

Regards,
Timur

-----Original Message-----
From: Marcel Reutegger [mailto:marcel.reutegger@gmx.net] 
Sent: Friday, February 18, 2005 9:39 AM
To: jackrabbit-dev@incubator.apache.org
Subject: Re: Query language issues

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