[
https://issues.apache.org/jira/browse/PHOENIX-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15585071#comment-15585071
]
Ankit Singhal commented on PHOENIX-3161:
----------------------------------------
bq. Does the HBase copy constructor not maintain the rawScan and cacheBlocks
values correctly? If not can you comment there and reference the HBase bug for
those?
Yes, Scan copy constructor is copying attributes and cachBlocks property. so
removed the extra updates to newScan from patch.
bq. Don't change the setTimeRange(Scan,long) method, but use the
setTimeRange(Scan,long,long) method instead. I'm not sure all the callers would
expect the min time range to come from the Scan passed in. Will that work for
you?
Yes, updated the patch to use setTimeRange(Scan,long,long) ,though
setTimeRange(Scan,long) was getting used by PostDDLCompiler.
bq. I don't think this fix is correct (and maybe you already made a related
fixed that we should look at too, though perhaps I reworked that already?). We
want minTimeStamp to be the smallest value of all the kv.getTimestamp() we see.
It's basically "how far back in time do we need to query".
We have already fix it in other JIRA(PHOENIX-3331), the change was to get
minTimeStamp of all KVs only.
{code}
- if (minTimeStamp == 0 || (kv.getTimestamp() >= 0 && minTimeStamp <
kv.getTimestamp())) {
+ if (minTimeStamp == 0 || (kv.getTimestamp() >= 0
&& minTimeStamp > kv.getTimestamp())) {
{code}
bq. I thought that region.batchMutate() won't invoke coprocessors like
htable.batch() does?
Yes ,it call coprocessors like htable.batch().
bq. Do existing tests pass with your patch?
yes all tests were passed. MutableIndexIT is mainly testing this.
bq. FWIW, we'd like to change the coprocessor code to use htable.batch()
instead (see PHOENIX-3271) so that we can execute UPSERT SELECT on the
server-side instead of bringing all the data back to the client-side, even if
the source and target tables are different (if auto commit is on). Would love
it if you could tackle that one next.
sure, I can try to take it next.
> Check possibility of moving rebuilding code to coprocessor of data table.
> -------------------------------------------------------------------------
>
> Key: PHOENIX-3161
> URL: https://issues.apache.org/jira/browse/PHOENIX-3161
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: Ankit Singhal
> Assignee: Ankit Singhal
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3161.patch, PHOENIX-3161_v1.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
