[
https://issues.apache.org/jira/browse/PHOENIX-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14313366#comment-14313366
]
James Taylor commented on PHOENIX-1580:
---------------------------------------
Thanks for the patch, [~ayingshu]. I think it'll be easier to model the union
chained off of SelectStatement rather than treating these as a set of
SelectStatements. So you'd add a SelectStatement union member variable on
SelectStatement in this case. Otherwise, things like bind variables will be
tricky to get right. I don't think any changes to PhoenixResultSet or
PhoenixStatement should be necessary. Instead, in
QueryCompiler.compileSingleQuery(), you can detect if the SelectStatement is a
union and call a new QueryCompiler.compileUnionQuery() with a corresponding new
UnionPlan.
- QueryCompiler.compileUnionQuery() would compile each individual
SelectStatement, giving you back a QueryPlan for each one.
- It's here that you'd compare the number and column types (from the
RowProjector off of each QueryPlan).
- The top level iterator from your QueryCompiler.compileUnionQuery() would be
combined together in a ConcatResultIterator.
- Any particular reason you're not allowing LIMIT or ORDER BY? I think those
should be allowed.
- You shouldn't need to deal with creating Callables and threading in general.
- Joins and derived queries, etc. will be interesting. [~maryannxue] can likely
give you some advice here.
> Support UNION ALL
> -----------------
>
> Key: PHOENIX-1580
> URL: https://issues.apache.org/jira/browse/PHOENIX-1580
> Project: Phoenix
> Issue Type: Bug
> Reporter: Alicia Ying Shu
> Assignee: Alicia Ying Shu
> Attachments: unionall-wipe.patch
>
>
> Select * from T1
> UNION ALL
> Select * from T2
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
