I agree with Stack. Was typing up a reply to Anoop but let me move it down here.
The type code exposes some low level details of how our current stores are architected. But what if in the future you could swap out HStore implements Store with PStore implements Store, where HStore is backed by HFiles and PStore is backed by Parquet? Just as a hypothetical example. I know there would be larger issues if this were actually attempted. Bear with me. You can imagine some different new Store implementation that has some advantages but is not a design derived from the log structured merge tree if you like. Most values from a new Cell.Type based on KeyValue.Type wouldn't apply to cells from such a thing because they are particular to how LSMs work. I'm sure such a project if attempted would make a number of changes requiring a major version increment and low level details could be unwound from Cell then, but if we could avoid doing it in the first place, I think it would better for maintainability. On Thu, Sep 28, 2017 at 9:39 AM, Stack <st...@duboce.net> wrote: > On Thu, Sep 28, 2017 at 2:25 AM, Chia-Ping Tsai <chia7...@apache.org> > wrote: > > > hi folks, > > > > User is allowed to create custom cell but the valid code of type - > > KeyValue#Type - is declared as IA.Private. As i see it, we should expose > > KeyValue#Type as Public Client. Three possible ways are shown below: > > 1) Change declaration of KeyValue#Type from IA.Private to IA.Public > > 2) Move KeyValue#Type into Cell. > > 3) Move KeyValue#Type to upper level > > > > Any suggestions? > > > > > What is the problem that we are trying to solve Chia-Ping? You want to make > Cells of a new Type? > > My first reaction is that KV#Type is particular to the KV implementation. > Any new Cell implementation should not have to adopt the KeyValue typing > mechanism. > > S > > > > > > -- > > Chia-Ping > > > > > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
