Just for documentation purposes (as no one seems to care on this list).
Maybe some day this will help someone who searches for a problem like
this via google.
As stated before you cannot query [jcr:path] via JCR SQL2 with
Jackrabbit 2.6.4 if you use a JOIN. You have to fetch if separately then
for each row, which means another roundtrip.
I ended up creating a custom mixin with all the properties I need. I
added this mixin to all my nodes and just use queries that return a
[jcr:path] (that means queries which do not join but rather have a
[jcr:primaryType] in the where clause.
This way I could improve my performance by a huge(!) factor: 20 seconds
with NodeIterator for maybe 50 nodes, now a few microseconds, it seems
like it's local.
For Fulltextsearch I used xpath, because, as stated before, I couldn't
join in JCR SQL2 without losing the jcr:path. Who cares if its
deprecated. Who cares if it's the right way to do it. It's fast via
Davex and that's all my users and me care about.
HTH someone some day.
Am 17.11.2013 20:30, schrieb Datenheld:
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.
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.
Best regards,
Datenheld
