jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@adobe.com>
Subject Re: Select jcr:path in JCR SQL2
Date Tue, 19 Nov 2013 00:10:43 GMT

On 17.11.2013, at 11:30, Datenheld <Datenheld@gmx.de> wrote:

> Hi again,
> here's a question about jcr:path in queries.
> Consider the following query:
> SELECT base.[jcr:path], content.[jcr:lastModified], 
> content.[jcr:lastModifiedBy] FROM [nt:base] as base LEFT OUTER JOIN 
> [nt:resource] as content ON ISCHILDNODE(content, base) WHERE 
> ((base.[jcr:primaryType] = 'nt:file' OR base.[jcr:primaryType] = 
> 'nt:folder') AND ISCHILDNODE(base, ['/some/path']))
> How come that base.[jcr:path] is always null? I read somewhere on the 
> web that jcr:path is a time-intensive calculation and that the field can 
> be omitted. Can I force the query to calculate the path?
> The whole point of this is a performance optimiziation. As NodeIterator 
> is slow and the query is fast I wanted to operate on paths only.  Sadly, 
> I can now get anything very fast, but the most important thing - the path.

Have you tried Row#getPath (since jcr 2.0) [0]?

What columns/properties you SELECT (including the "jcr:path") should be irrelevant to the
performance, only the query (aka WHERE and JOINs) can make a difference. This is because the
query will resolve to nodes either way, as JCR queries can only result in a list of nodes
(regardless of using a NodeIterator or RowIterator, the row iterator just gives a column-like
view on top of a list of nodes). 

If you set column names in a query, the row iterator merely denies access to the other ones
in the API, but the dynamic options (jcr:score, rep:spellcheck, rep:excerpt or jcr:path) are
all calculated on-demand (i.e. in row.getValue()) and jcr:path is the same as calling node.getPath(),
so the statement you found on the web that it is a time-intensive calculation is not true.

> So, is there a way to retrieve the paths when you have a query with 
> joins? Or will I really have to call row.getPath("<selector>") which 
> slows everything down again.

Hmm, maybe that's a spi/remoting limitation...

Regarding the query: an nt:folder cannot have a nt:resource child, and nt:file defines the
child as jcr:content, so your query can be simplified to this xpath query:

/jcr:root/some/path//element(*, nt:file)/jcr:content

(I personally think xpath is much better suited for hierarchical structures, and it's rare
that you really need a complex JOIN only supported by jcr-sql2; also, xpath is deprecated
in the JCR spec, but not in Jackrabbit; the intention of the spec writers is even if it is
not supported through the jcr API, a repository would offer a generic xpath-2-aqm conversion).

[0] http://www.day.com/maven/javax.jcr/javadocs/jcr-2.0/javax/jcr/query/Row.html#getPath()


View raw message