[
https://issues.apache.org/jira/browse/OAK-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13832660#comment-13832660
]
Thomas Mueller commented on OAK-1215:
-------------------------------------
OK, so the real query is
{code}
/jcr:root/etc/commerce/products//*[@cq:commerceType='product' and (@size='M' or
*/@size='M' or */*/@size='M')]
{code}
? And the original query (the one that doesn't filter on commerceType) is just
to illustrate the incompatibility?
Would an index on the property cq:commerceType be sufficiently fast? (How many
nodes are there with cq:commerceType='product', and how many nodes are there
with size='M' in the whole repository?)
> Or perhaps you meant translating the XPath to SQL-2 inside Oak?
The XPath - to - SQL-2 converter could in theory create the outer join Jukka
was suggesting, but that would be quite tricky. It's an option, but I wouldn't
want to go in this direction if possible. I was thinking, we could convert the
XPath query to
{code}
SELECT a.* FROM [nt:base] AS a
WHERE ISDESCENDANTNODE(a, [/etc/commerce/products])
AND [cq:commerceType]='product'
AND (a.[size]='M' OR a.[*/size]='M' OR a.[*/*/size]='M')
{code}
and then use an index on the property "cq:commerceType". This would require
supporting "*/size" and so on within the query engine, but it wouldn't easily
allow using an index on the property "size"
> Relative property paths don't work in XPath search expressions
> --------------------------------------------------------------
>
> Key: OAK-1215
> URL: https://issues.apache.org/jira/browse/OAK-1215
> Project: Jackrabbit Oak
> Issue Type: Bug
> Reporter: Jeff Young
> Priority: Critical
> Attachments: relative-predicate-paths.tiff
>
>
> A search XPath of the form:
> {code}
> /jcr:root/etc/commerce/products//*[@size='M' or */@size='M']
> {code}
> returns:
> {code}
> Invalid path: *
> {code}
> (This works fine in Jackrabbit.)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
