jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-2852) Support multi-selector OR constraints in join queries
Date Thu, 10 Mar 2011 11:41:59 GMT

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

Jukka Zitting commented on JCR-2852:

Looks good, thanks! I committed the patch in revision 1080186.

Some comments:

* The many "if (multiple)" conditions in ConstraintSplitInfo and related code suggest that
we might want to use the strategy pattern instead of treating ConstraintSplitInfo as just
a data class. Something like that could also simplify the current ConstraintSplitter class.

* I find the "if (...) { ...; return; } ...;" pattern you use somewhat confusing. I'd rather
just use "if (...) { ...; } else { ...; }". If that leads to too much indentation, it's time
to break the method to smaller subtasks.

* It would be good to have an outer join test case as well. I'm not sure how the OR conditions
interact with outer join semantics.

* I removed some trailing whitespace from here and there in the patch. Not a big 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.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