[
https://issues.apache.org/jira/browse/HBASE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635840#action_12635840
]
jimk edited comment on HBASE-880 at 9/30/08 1:26 PM:
--------------------------------------------------------------
@Stack
{quote}
Looking at this, regards RowOperation, don't you think the timestamp belong
rather with the specification of what we're
to get or delete or update? If we do this, it facilitates batching a bunch of
operations against the one row but each with
its own timestamp specification (and +1, the timestamp needs to be specifiable
as a range with start and end for all
Operations).
{quote}
Neither the current API nor the 880 patch supports different timestamps for
update, get(column) or getRow.
Are you proposing we add this?
Only gets and deletes have a startingTimestamp. Doesn't make sense for puts.
{quote}
Is it true that we cannot do a mix of update/get/deletes on the one row all in
the one operation (as was possible with
old BatchUpdate)
{quote}
Neither trunk nor 880 patch permit that, although my earlier proposal did. The
problem I found with that was in
returning results. As you pointed out in an earlier comment, get(column) should
return Cell[] and getRow should
return a RowResult (or as I suggested a SortedMap<byte[], Cell>)
{quote}
IIRC, doing the below was problematic:
public RowResult getRow(RowGet) could be changed to return SortedMap<byte[],
Cell>
{quote}
HBaseMapWritable implements SortedMap<byte[], Cell> and getRow does not need
the row back. Is it possible
that at one point HBaseMapWritable implemented Map<byte[], Cell> and not
SortedMap?
{quote}
-1 on 'Rename RowUpdate to RowMutation.' IMO, mutation is c++ speak whereas
update is db speak.
{quote}
Jean-Daniel agrees with you and I don't really care what we call it. I used
mutation because that is what
Bigtable calls it.
{quote}
On constructors vs. setters, this is an age-old argument. Lets have one or the
other, not both. If lots of arguments,
that would seem to favor setters though invoking all the setters on a newly
created object makes for ugly code and
possibly half-initialized objects - and I dislike the fact that setters makes
our objects mutable.
{quote}
I agree. I used setters for a lot of stuff because it reduced the number of
overloads by a lot, especially in derived
classes, which had to take all the possible arguments for their super classes.
With respect to half-initialized objects, I would imagine that the things that
can be set would be initialized to
a default value that makes sense.
And I agree on the mutability issue, but I think the trade-off is worth it.
was (Author: jimk):
@Stack
{quote}
Looking at this, regards RowOperation, don't you think the timestamp belong
rather with the specification of what we're
to get or delete or update? If we do this, it facilitates batching a bunch of
operations against the one row but each with
its own timestamp specification (and +1, the timestamp needs to be specifiable
as a range with start and end for all
Operations).
{quote}
The neither the current API nor the 880 patch does not support different
timestamps for update, get(column) or getRow.
Are you proposing we add this?
Only gets and deletes have a startingTimestamp. Doesn't make sense for puts.
{quote}
Is it true that we cannot do a mix of update/get/deletes on the one row all in
the one operation (as was possible with
old BatchUpdate)
{quote}
Neither trunk nor 880 patch permit that, although my earlier proposal did. The
problem I found with that was in
returning results. As you pointed out in an earlier comment, get(column) should
return Cell[] and getRow should
return a RowResult (or as I suggested a SortedMap<byte[], Cell>)
{quote}
IIRC, doing the below was problematic:
public RowResult getRow(RowGet) could be changed to return SortedMap<byte[],
Cell>
{quote}
HBaseMapWritable implements SortedMap<byte[], Cell> and getRow does not need
the row back. Is it possible
that at one point HBaseMapWritable implemented Map<byte[], Cell> and not
SortedMap?
{quote}
-1 on 'Rename RowUpdate to RowMutation.' IMO, mutation is c++ speak whereas
update is db speak.
{quote}
Jean-Daniel agrees with you and I don't really care what we call it. I used
mutation because that is what
Bigtable calls it.
{quote}
On constructors vs. setters, this is an age-old argument. Lets have one or the
other, not both. If lots of arguments,
that would seem to favor setters though invoking all the setters on a newly
created object makes for ugly code and
possibly half-initialized objects - and I dislike the fact that setters makes
our objects mutable.
{quote}
I agree. I used setters for a lot of stuff because it reduced the number of
overloads by a lot, especially in derived
classes, which had to take all the possible arguments for their super classes.
With respect to half-initialized objects, I would imagine that the things that
can be set would be initialized to
a default value that makes sense.
And I agree on the mutability issue, but I think the trade-off is worth it.
> Improve the current client API by creating new container classes
> ----------------------------------------------------------------
>
> Key: HBASE-880
> URL: https://issues.apache.org/jira/browse/HBASE-880
> Project: Hadoop HBase
> Issue Type: Improvement
> Components: client
> Reporter: Jean-Daniel Cryans
> Assignee: Jean-Daniel Cryans
> Fix For: 0.19.0
>
> Attachments: hbase-880-patch.jpg, hbase-880-v1.patch,
> hbase-880-v2.patch, hbase_client_classes.png, proposed.jpg
>
>
> The current API does not scale very well. For each new feature, we have to
> add many methods to take care of all the overloads. Also, the need to batch
> row operations (gets, inserts, deletes) implies that we have to manage some
> "entities" like we are able to do with BatchUpdate but not with the other
> operations. The RowLock should be an attribute of such an entity.
> The scope of this jira is only to replace current API with another
> feature-compatible one, other methods will be added in other issues.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
