It is worth taking look at: https://issues.apache.org/jira/browse/HBASE-10390
-Vlad On Tue, Jan 26, 2016 at 11:26 AM, Yakubovich, Alexey < [email protected]> wrote: > I notices an unanswered question: “Check and Put method used with > a long)”. I would like to ask it in a slightly different form: > Can you customize (within reasonable restrictions)) the > condition for the atomic update? > > The HTable method > > checkAndPut(byte[] row, > byte[] family, > byte[] qualifier, > CompareFilter.CompareOp< > https://archive.cloudera.com/cdh5/cdh/5/hbase/devapidocs/org/apache/hadoop/hbase/filter/CompareFilter.CompareOp.html> > compareOp, > byte[] value, > Put< > https://archive.cloudera.com/cdh5/cdh/5/hbase/devapidocs/org/apache/hadoop/hbase/client/Put.html> > put) > > Uses the CompareFilter.CompareOp enum. But what I would like is the > complete customization of compareOp, with my own logic. > > And still, can you apply the existing checkAndPut with compareOp on a > field that contains integer, or long, of my own class (in binary form)? > (and naturally I need GREATER be in context of java.lang.Integer, not > binary strings that represent integers). > > Or, if not, how to solve the following use case: > > Several spark executors updating the data structurer (in HBase table) that > contains record as > > (pid:String, hits:int) > > I want the update only happens if the new value for the field hits is > grater that the current value. > Now suppose one of executors (E1) has a new value (V1) for the given pid. > If it operates non-atomically it could read current value V0, compare with > new value and tries to update (if V1 > V0). But it could happen that > current value was already been increased to V2 by another executor. The E1 > knows the prev. value and could use regular checkAndPut, so that update > would not happen if current value was changed, but E1 still does’t know if > new value (V1) is bigger than updated current value (V2), and and has no > way but to attempt the same update again… (if V1 >V2). > > I hope I described the use case clearly, it seems very typical and > elementary one. Can somebody please hint how to solve it? > Thank you > Alexey > > This message, including any attachments, is the property of Sears Holdings > Corporation and/or one of its subsidiaries. It is confidential and may > contain proprietary or legally privileged information. If you are not the > intended recipient, please delete it without reading the contents. Thank > you. >
