bq. CellBuilder#DataType that produces Cell that has getTypeByte method which returns "The byte representation of the KeyValue.TYPE". That is a workaround that makes all parameters IA.Public to create cell. (-_-) The root cause is the cell interface expected to be a general data has many methods which belong to current LSM storage.
On 2017-10-28 08:21, Sergey Soldatov <[email protected]> wrote: > bq. Here is the DataType I was talking about: > > Ah, thanks, Ted! Forgot to make the pull. According to the HBASE-18927 as > well as the discussion that had a place before that, It addresses exactly > the topic we are discussing. But actually, it didn't solve the problem and > just created more ambiguity. We have CellBuilder that requires > CellBuilder#DataType that produces Cell that has getTypeByte method which > returns "The byte representation of the KeyValue.TYPE". > > bq. I more think that the maybe getType() was misintepreted from what Nick > originally meant it to be. Maybe intentional, maybe not. > > If I remember correctly HBASE-8693 was about the encoding for commonly used > data types to keep them sorted in native order. Similar to PData types in > Phoenix. > > bq. You agree with Ram's suggestion for helper methods as a way forward? > > Well, we already have helpers for all types except Put/Minimum. Adding one > more is not a big deal. But deprecating getters sounds like a bad idea. For > example, the timestamp is used by many 3rd parties to do their own > transactional/versioning support and actually, it's a part of the public > API. If we may specify timestamp for the cell, why we should restrict users > from reading it? Others fields may be useful for creating a modified copies > of the KV like we do in our custom StoreFileReader for local indexes. > > Thanks, > Sergey > > On Fri, Oct 27, 2017 at 10:40 AM, Chia-Ping Tsai <[email protected]> > wrote: > > > bq. You agree with Ram's suggestion for helper methods as a way forward? > > Adding the CellUtil#isPut() is ok to me as the PUT is a basic operation in > > hbase. > > > > On 2017-10-28 00:58, Josh Elser <[email protected]> wrote: > > > Re-reading https://issues.apache.org/jira/browse/HBASE-8693 that Sergey > > > pointed out, I more think that the maybe getType() was misintepreted > > > from what Nick originally meant it to be. Maybe intentional, maybe not. > > > > > > I don't think getTimestamp() should be removed -- when we store multiple > > > versions of a Key, users should be able to reconcile the Cells client > > > side (e.g. consider a CP which performs some custom merging logic). > > > > > > getSequenceId() I'd agree probably doesn't belong. getTag() I'll hold > > > off judgement because I'm constantly biased into thinking the feature is > > > something that it isn't :) > > > > > > You agree with Ram's suggestion for helper methods as a way forward? > > > > > > On 10/27/17 7:29 AM, Chia-Ping Tsai wrote: > > > > The CellBuilder#Data type is introduced to make sure all components > > used to builder cell are IA.Public. > > > > > > > > bq. Best as I can tell, Cell#getType() should be deprecated > > > > As i see it, the Cell#getType, #getTimestamp, #getSequenceId, and > > #getTag should be deprecated as these methods is some kind of internal info > > of storage engine. As a key-value store, the key consisting of row, > > family, and qualifier is enough to the general purpose. Other fields belong > > to the specific storage engine, and they should not be in the Cell which is > > our "frontline" interface of data. > > > > > > > > > > > > On 2017-10-27 06:40, Josh Elser <[email protected]> wrote: > > > >> Hiya, > > > >> > > > >> (Background: see HBASE-19002) > > > >> > > > >> In trying to write some example Observers, I found myself in a pickle: > > > >> how do I tell if a Cell is a Put? > > > >> > > > >> * Cell#getType() returns a byte which corresponds to a KeyValue.Type > > > >> * KeyValue.Type has API to convert a byte to Type > > > >> * KeyValue (and thus KeyValue.Type) is IA.Private > > > >> * DataType o.a.h.h.typesDataType _appears to me_ to be the replacement > > > >> for the KeyValue.Type > > > >> > > > >> Best as I can tell, Cell#getType() should be deprecated and we should > > > >> have some kind of API (method on Cell or CellUtil) which returns a > > > >> DataType instead of Type. The details of the byte and the > > KeyValue.Type > > > >> should be hidden inside the implementation. > > > >> > > > >> My hunch is that this is an accidental omission, but Stack recommended > > > >> that I "ask the class" ;). What have I missed? I think this is trivial > > > >> to fix; obviously, I don't want to make a fix if I just didn't look > > hard > > > >> enough. > > > >> > > > >> Thanks! > > > >> > > > >> - Josh > > > >> > > > > > >
