jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Federico Grilli (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-2852) Support multi-selector OR constraints in join queries
Date Tue, 28 Jun 2011 10:42:17 GMT

    [ https://issues.apache.org/jira/browse/JCR-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13056440#comment-13056440
] 

Federico Grilli commented on JCR-2852:
--------------------------------------

Hi, I just updated to jackrabbit 2.2.7. The {{javax.jcr.UnsupportedRepositoryOperationException:
Unable to split a constraint that references both sides of a join.}} exception is actually
gone but another issue seems to have arisen. I have a query like this 
{{select mytype.* from [my:type] as mytype inner join [my:child] as mychild on ischildnode
(mychild, mytype) where contains(mytype.*, 'foo') or contains(mychild.*, 'foo')}}
Regardless of whether _foo_ is there or not, the entire dataset is returned every time.

> 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
>            Assignee: Alex Parvulescu
>             Fix For: 2.2.7
>
>         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

        

Mime
View raw message