jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Parvulescu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-2852) Support multi-selector OR constraints in join queries
Date Fri, 01 Apr 2011 16:49:05 GMT

    [ 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.
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'
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

View raw message