On Sun, Jul 28, 2013 at 5:43 PM, Andrew Purtell <apurt...@apache.org> wrote:
> On Sun, Jul 28, 2013 at 4:01 PM, Stack <st...@duboce.net> wrote: > > > I just did a review of tags. They look like they need a good bit of > > work yet. > > > > Yes that patch I put up on RB is the one that was cluster tested and > profiled. Let me work with Ram about getting the latest up there. We also > needed to get a sense of what can work. For that, please correct me if I am > mistaken about any of the following: > > - An HFileV3 is fine in concept. > > Yes. In the patch, it looks to me that v3 is not a true new type but just an h2 w/ tags shoehorned in. Going forward v3 will not be extensible as done. It might as well be called h2+tags? > - We subclass KeyValue (as TaggedKeyValue) to avoid changing KeyValue's > serialization code and to avoid heap size inflation for the no tags > case. > This is fine modulo issues with encapsulation. > > Yes. > - Not plumbing tags all the way through to the client as to minimize > risk in 0.96 is ok. (And this benefits security as a bonus and is also > fine > for strictly server-side tag use cases.) This ties in to the above as to > why a subclass is needed to carry around tags as in memory state, like > memstoreTS. > > Yes > - Changing the encoders is fine, since they are shared by all HFile > implementations. Of course as few changes as possible. Tag specific > changes > there - method signature changes mostly - are currently workable but > ugly, > but we can handle that in another pass by subclassing more HFile > classes to > carry V3 specific state. > > Yes. Thanks. St.Ack
