jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øyvind Stegard <oyvind.steg...@usit.uio.no>
Subject Re: JCR 1.0 SQL queries with JackRabbit
Date Tue, 18 Mar 2008 12:53:39 GMT
man, 17.03.2008 kl. 15.36 +0100, Marcel Reutegger:
> Hi Øyvind,
> 
Hi !

<snip>
> In JCR 1.0 only one basic path constraint per query is possible. It boils down to:
> 1) a node with a given path
> 2) nodes, which are children of a given path
> 3) nodes, which are descendants of a given path
> 
Ok. What confuses me somewhat by this is that the spec says that
descendant or self must be supported (section 6.6.3.4 "Path Constraint",
page 108). Maybe there's something I've misunderstood, it's not really a
big deal.

<snip>
> > 2)
> > Is there any feasible way of querying for path depth using the jcr:path
> > pseudo property ? When talking about "path depth", I am only concerned
> > about absolute node paths, where "/" has depth 0, "/foo" has depth 1 and
> > so on. It is the same as the depth concept in
> > org.apache.jackrabbit.spi.Path#getDepth(), but only for absolute paths. 
<snip>
> no, this is not possible with SQL but you can use XPath:
> 
> /jcr:root/*/*[@jcr:primaryType = 'nt:file' or @jcr:primaryType = 'nt:folder']
> 
> or you can use the common base type:
> 
> /jcr:root/*/element(*, nt:hierarchyNode)
> 
I see, that works well :)


<snip>
> > It seems that logical inversion of LIKE queries on jcr:path is ignored
> > by JackRabbit.
> > 
> > Two examples:
> > 
> > SELECT * FROM nt:base WHERE jcr:path NOT LIKE '/foo/%'
> > and
> > SELECT * FROM nt:base WHERE NOT (jcr:path LIKE '/foo/%')
<snip>
> This is a bug in Jackrabbit and should actually throw an InvalidQueryException.
> 
Ok.


> > 4)
> > It seems that "NOT LIKE .." generally does not invert matching for any
> > kind of JCR property ?
> 
> JCR 1.0 does not specify a <property-name> NOT LIKE <string-literal>, which

> means jackrabbit should probably also throw an InvalidQueryException in this case.
> 
> > However, I could work around that by wrapping a
> > regular "LIKE" inside a NOT(...) expression, i.e. "NOT (foo:bar LIKE
> > 'baz%')". Perhaps that's not very wise, performance-wise (pun
> > intended) ?
> 
> yes, and it's also not exactly the same. While foo:bar not like 'baz%' returns 
> all nodes with a foo:bar not starting with 'baz', not(foo:bar like 'baz%') will 
> also return nodes that do not even have the property.
Ah, I realize this now. Perhaps I can add a
".. AND foo:bar IS NOT NULL"-clause which should fix that logical flaw.


<snip>
> > What should we expect of support for these types of queries in future
> > versions of JackRabbit, JCR 2.0, etc ?
> 
> The features that Jackrabbit will support in the future will be those defined in 
> JSR 283. You can download the public preview here: 
> http://jcp.org/aboutJava/communityprocess/pr/jsr283/
> 
Yes, I've been causally browsing this document for a while. Looking at
the roadmap for the JackRabbit project, I see that JCR2.0-support is in
the medium term time category, any rough ideas of how long that actually
is :) ? I can't seem to find any indications elsewhere.


> In addition there will be Jackrabbit proprietary extensions driven by the 
> user/developer community. We did this already in the past when we saw a need for 
> certain features that were not specified in JSR 170.
> 


Thanks for the reply ! 

Regards,
Øyvind S.
-- 
< Øyvind Stegard ~ oyvind stegard at usit uio no
 < USIT, UiO


Mime
View raw message