[
https://issues.apache.org/jira/browse/PHOENIX-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329172#comment-14329172
]
Maryann Xue commented on PHOENIX-1489:
--------------------------------------
Ignore my previous comment (deleted). I assume it's still compatible. There are
two things concerning this change:
1. For a join query projection: In the new client, the "forceProjection" flag
is always serialized as true. And the old HashJoinRegionScanner would take this
flag and always project the row at the very beginning of the join operation,
which is the same behavior with the new HashJoinRegionScanner.
2. For a single query projection: In the new server code, we would have
BaseScannerRegionObserver.getWrappedScanner to do the job instead of initiating
a HashJoinRegionScanner even without any join operation. But in the old server
code, the HashJoinRegionScanner would do the job, exactly the same way. Both
the scan attribute name and the attribute content have not changed between two
versions.
Anyway, I will verify it before check-in. However, there is one minor issue
with backward compatibility, which would cause scenario in
MappingTableDataTypeIT to fail (which expects a exception to be throw for a
value of incorrect byte length). Now that we evaluate and project KeyValues on
the server side, the tuple projection should be responsible for checking the
data length. This is actually a bug I fixed for KeyValueSchema in this patch.
It should have checked ptr length before returning the value, and the maxOffset
should not be the total length of ptr but instead should be the total length
minus bitSet length. I would like to check in this small bug fix to 4.3 if
possible.
> Access column values positionally from client
> ---------------------------------------------
>
> Key: PHOENIX-1489
> URL: https://issues.apache.org/jira/browse/PHOENIX-1489
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: James Taylor
> Assignee: Maryann Xue
> Attachments: 1489-2.patch, 1489-v1.patch, 1489-v3.patch
>
>
> Instead of passing back separate KeyValues for data returned from the server,
> we should access via position using our TupleProjector everywhere. This is
> already the case for joins and aggregate queries, but not for scan queries.
> We can modify ScanRegionObserver to use our KeyValueSchema to accomplish this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
