[
https://issues.apache.org/jira/browse/HBASE-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703706#action_12703706
]
Erik Holstad commented on HBASE-1304:
-------------------------------------
+ Yes multiFamily is a boolean that I thought would live in HCD, but I don't
have any preferences in this case and I don't know how the client would count
that, but that might be really easy.
+ The reason that I put MAX_FMAILY_LENGTH in HConstant was that MAX_ROW_LENGTH
was already in there so I thought that it was the place to put things like that.
+ In KeyValue, this might be the case that the stuff that I added are already
in there, will try to change that when going through the code. Yes the set
method is not needed, not sure right now why I put that there.
+ So the reasoning around the naming is that the names that I'm using now are
just working names, I run both old implementations side by side, so I can
compare the codes and behaviour between them. I don't intend to keep all the
new names when I got this to work, only used for debugging purposes.
+ The reason behind having different classes for the different Get types is
more a way to explain to the user that the calls behave differently and has
really nothing to do with the underlying implementation, like you say they
could all pretty much be one class, and they also are in the background.
+ GetTop is not aimed for getting versions it is for getting the first columns
in a family, if you for let's say are putting the timestamp in the column name
and want to fetch the most recent insert, this is when you would use GetTop
instead of Get with versions.
+ RowUpdates are carrying KeyValues, but the way I have done it now, this is
transparent to the user and is done at commit time, could definitely be changed.
+ newGet, see above.
+ Not really sure what you mean with that Family is being used as a byte[] on
the server side. I totally agree that we should try to send as few bytes as
possible over the wire, but to me it
isn't that obvious that including the family in every byte[] together with the
columnName will be less than putting the familyName once and only putting the
columns in a list and wrapping this in an object will be bigger.
+ Are you referring to isDeleted? Yes, this code could live somewhere else, but
it is just that it has state, so then you need to have state where it lives.
Just seemed easy to have all the things that are related to the
compareTo(KeyValue) live in the same place for now, since they all interact
with each other.
> New client server implementation of how gets and puts are handled.
> -------------------------------------------------------------------
>
> Key: HBASE-1304
> URL: https://issues.apache.org/jira/browse/HBASE-1304
> Project: Hadoop HBase
> Issue Type: Improvement
> Affects Versions: 0.20.0
> Reporter: Erik Holstad
> Assignee: Erik Holstad
> Priority: Blocker
> Attachments: hbase-1304-v1.patch
>
>
> Creating an issue where the implementation of the new client and server will
> go. Leaving HBASE-1249 as a discussion forum and will put code and patches
> here.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
