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
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.
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
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>)
IIRC, doing the below was problematic:
public RowResult getRow(RowGet) could be changed to return SortedMap<byte, Cell>
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?
-1 on 'Rename RowUpdate to RowMutation.' IMO, mutation is c++ speak whereas update is db speak.
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.
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.
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.