[
https://issues.apache.org/jira/browse/JCR-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13014734#comment-13014734
]
Alex Parvulescu commented on JCR-2852:
--------------------------------------
Apparently JCR-2933 stumbled upon a case that does not fit into my patch :(
If we have an outer join with an OR condition that references the 2 sides of
the join on both branches of the condition. The Constraint splitter fails to
recognize that and executes 2 wrong queries, thus resulting in a 0 set.
Ex:
Select * from [test:SamplePage] as page left outer join [test:SampleContent] as
content on ISDESCENDANTNODE(content,page) where (page.prop1 = 'page1' and
content.prop1 = 'content3') or (page.prop1='page2' and content.prop1='content3')
The Or has 2 branches that reference both sides:
1. page.prop1 = 'page1' and content.prop1 = 'content3'
OR
2. page.prop1='page2' and content.prop1='content3'
A suggested workaround (as I think this will have horrible performance anyway)
is to rewrite the query in a more simple way to not cross reference anymore:
where (page.prop1 = 'page1' or page.prop1='page2') and content.prop1 =
'content3'
but this does not fix the issue
> Support multi-selector OR constraints in join queries
> -----------------------------------------------------
>
> Key: JCR-2852
> URL: https://issues.apache.org/jira/browse/JCR-2852
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core, query
> Reporter: Jukka Zitting
> Attachments: JCR-2852-NPE.patch, JCR-2852-outer-join-test.patch,
> JCR-2852.patch
>
>
> Our current join implementation doesn't support OR constraints that refer to
> more than one selector. For example the following query is not possible:
> SELECT a.* FROM [my:type] AS a INNER JOIN [my:type] as b ON a.foo = b.bar
> WHERE a.baz = 'x' OR b.baz = 'y'
> This limitation is a result of the way the join execution splits the query
> into per-selector components and merges the result based on the given join
> condition.
> A simple but often inefficient solution would be to process such OR
> constraints as post-processing filters like we already do for some other more
> complex constraint types.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
