[
https://issues.apache.org/jira/browse/OMID-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17580455#comment-17580455
]
ASF GitHub Bot commented on OMID-223:
-------------------------------------
gjacoby126 commented on code in PR #109:
URL: https://github.com/apache/phoenix-omid/pull/109#discussion_r947220162
##########
hbase-coprocessor/src/main/java/org/apache/omid/transaction/CellSkipFilterBase.java:
##########
@@ -53,21 +53,21 @@ public CellSkipFilterBase(Filter filter) {
*/
private boolean skipCellVersion(Cell cell) {
return skipColumn != null
- && CellUtil.matchingRow(cell, skipColumn.getRowArray(),
skipColumn.getRowOffset(),
+ && PrivateCellUtil.matchingRows(cell, skipColumn.getRowArray(),
skipColumn.getRowOffset(),
Review Comment:
@stoty @Aarchy - Agreed. I also don't see an alternative to using an
IA.Private class here. Given the choice between KeyValueUtil / KeyValue, and
the PrivateCellUtil's createFirstOnRow function, I think the latter's the
better option.
It keeps the interface encapsulation around Cell and doesn't require Phoenix
code to make assumptions about whether the Cell is an array-backed on-heap
object or an off-heap byte-buffer backed object.
Rushabh Shah and I once asked to allow PrivateCellUtil to be
IA.LimitedPrivate(COPROC) on HBASE-25328, which the HBase community was not
willing to do. Instead they were willing to expose new LimitedPrivate helper
methods in HBase that called particular IA.Private methods we needed. Probably
not a good time with HBase 2.5 about to release, but that's something we could
pursue in the future.
This does of course mean we're accepting the risk that this method can
change arbitrarily with every HBase upgrade.
> Refactor Omid to use HBase 2 APIs internally.
> ---------------------------------------------
>
> Key: OMID-223
> URL: https://issues.apache.org/jira/browse/OMID-223
> Project: Phoenix Omid
> Issue Type: Improvement
> Reporter: Istvan Toth
> Assignee: Aron Attila Meszaros
> Priority: Major
> Attachments: OMID-223-wip.patch
>
>
> Omid currently uses HBase 1 APIs everywhere.
> This made sense when HBase 1 and 2 had to be supported from the same codebase.
> However, as we're dropping HBase 1 support, this is a liability now.
> Doing this is also going to eventually make supporting HBase 3 much easier.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)