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

Sean Busbey commented on HBASE-15698:
-------------------------------------

[~sergey.soldatov] on the dev@phoenix list 
([ref|https://lists.apache.org/thread.html/Zaptnijtlufsk8p]) says

{quote}
Not sure about the unit test, but the fix that cause our issue is HBASE-15198. 
Prior it we had connection with cellBlock false, so protobuf serialized 
everything, including timeRange. Now cellBlock is true and 
buildNoDataRegionAction is used for the serializing of Increament mutations. 
And it doesn't even think about timeRange. If you want to reproduce it with 
phoenix, just get the workspace from the git on the commit provided in Jame's 
comments, build it with -DskipTests, import into IDE (I would recommend Idea 
since it's better handle generated files), place breakpoint in 
RequestConverter.buildNoDataRegionAction at Increment i = (Increment) row; Now 
run PhoenixTimeQueryIT in the debugger. Several steps and you will see that 
builder will be started with empty timeRangeBuilder_
{quote}

> Increment TimeRange not serialized to server
> --------------------------------------------
>
>                 Key: HBASE-15698
>                 URL: https://issues.apache.org/jira/browse/HBASE-15698
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 1.2.0, 1.3.0
>            Reporter: James Taylor
>            Assignee: Sean Busbey
>            Priority: Blocker
>              Labels: phoenix
>             Fix For: 1.3.0, 1.0.4, 1.2.2, 0.98.20, 1.1.6
>
>         Attachments: HBASE-15698.1.patch
>
>
> Before HBase-1.2, the Increment TimeRange set on the client was serialized 
> over to the server. As of HBase 1.2, this appears to no longer be true, as my 
> preIncrement coprocessor always gets HConstants.LATEST_TIMESTAMP as the value 
> of increment.getTimeRange().getMax() regardless of what the client has 
> specified.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to