[
https://issues.apache.org/jira/browse/HBASE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638045#action_12638045
]
stack commented on HBASE-880:
-----------------------------
I took at the new patch (thanks for exercising the proposal in code J-D).
Here's some suggestions. In general, would suggest that HbaseMapWritable with
all of its generics not be exposed to the user as Dogacan suggests, except we
don't do getter/setters by the million on Get as he suggests because IMO that
defeats point of introducing Scope object. HBW should be wrapped.
Is Specification a better name than Scope? The HbaseMapWritable making code
would be replaced by new wrapper class called Specifications where
Specifications is a map of column names to Specifications (or Scope and Scopes)
so that for example:
{code}
- Cell[] cells = this.metaTable.get(Bytes.toBytes(regionName),
- columnKey, ALL_VERSIONS);
- if (cells != null) {
- for (Cell cell : cells) {
+ HbaseMapWritable<byte[], Scope> col =
+ new HbaseMapWritable<byte[], Scope>();
+ Scope scope = new Scope();
+ col.put(columnKey, scope);
+ Get get = new Get(Bytes.toBytes(regionName), col);
+ RowResult rr = this.metaTable.getRow(get);
+ if (rr != null) {
+ for (Cell cell : rr.values()) {
{code}
became
{code}
- Cell[] cells = this.metaTable.get(Bytes.toBytes(regionName),
- columnKey, ALL_VERSIONS);
- if (cells != null) {
- for (Cell cell : cells) {
+ Specifications col = new Specifications();
+ col.put(columnKey, new Specification());
+ Get get = new Get(Bytes.toBytes(regionName), col);
+ RowResult rr = this.metaTable.getRow(get);
+ if (rr != null) {
+ for (Cell cell : rr.values()) {
{code}
Specifications could have a constructor that took key/Specification for case
where only one entry. Then you could do:
{code}
Get get = new Get(Bytes.toBytes(regionName), new Specifications(columnKey, new
Specification());
{code}
Or
{code}
- Cell cell = t.get(row, HConstants.COL_REGIONINFO);
- if (cell == null) {
+ Scope scope = new Scope();
+ HbaseMapWritable<byte[], Scope> hmw =
+ new HbaseMapWritable<byte[], Scope>();
+ hmw.put(HConstants.COL_REGIONINFO, scope);
+ Get get = new Get(row,hmw);
+ RowResult rr = t.getRow(get);
+ if (rr == null) {
{code}
becomes
{code}
- Cell cell = t.get(row, HConstants.COL_REGIONINFO);
- if (cell == null) {
+ Specifications specs = new Specifications(HConstants.COL_REGIONINFO, new
Scope());
+ Get get = new Get(row, specs);
+ RowResult rr = t.getRow(get);
+ if (rr == null) {
{code}
If the above pattern where Scope is empty of all but the defaults, then why not
a constructor on Get that takes just a column name?
Or
{code}
+ Scope scope = new Scope();
+ scope.setTimestamp(timestamp);
+ scope.setVersions(numVersions);
+ HbaseMapWritable<byte[], Scope> hmw = new HbaseMapWritable<byte[],
Scope>();
+ hmw.put(column, scope);
+ Get get = new Get(row, -1, hmw);
+ Collection<Cell> cells = getRow(get).values();
+ return cells.toArray(new Cell[cells.size()]);
{code}
becomes
{code}
+ Specification spec = new Specification();
+ spec.setTimestamp(timestamp);
+ spec.setVersions(numVersions);
+ Specifications hmw = new Specifications(column, spec);
+ Get get = new Get(row, -1, hmw);
+ Collection<Cell> cells = getRow(get).values();
+ return cells.toArray(new Cell[cells.size()]);
{code}
On single-cell get, lets add to Get a getCell that returns the old fashioned
byte []?
> 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-proposal4.patch,
> hbase-880-v1.patch, hbase-880-v2.patch, hbase_client_classes.png,
> NewCilentAPIProposoal4.gif, proposal2.jpg, 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.
