hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-1304) New client server implementation of how gets and puts are handled.
Date Fri, 08 May 2009 22:42:45 GMT

    [ https://issues.apache.org/jira/browse/HBASE-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707549#action_12707549
] 

stack commented on HBASE-1304:
------------------------------

toString format needs to change in Delete, Get, etc., to match how we toString elsewhere using
ruby-style for maps/arrays -- just for consistency sake.  Ruby-style is pretty much how java-style
works representing Maps and Lists and it matches shell.

Lets just drop RowLock from the new objects and use a long for lockid altogether?  Thats all
it is and one less object.  Also io package not referencing item in client package.

Below is odd especially when Get does not implement Map
{code}
+  public Set<Map.Entry<byte[],TreeSet<byte[]>>> entrySet() {
+    return this.familyMap.entrySet();
+  }
{code}

Check for null array here:

{code}
+  public Result(KeyValue [] kvs) {
+    this.row = kvs[0].getRow();
+    this.kvs = kvs;
+  }
{code}

Does Result get instantiated server-side?  Would be nice if it wasn't; if Clients made it,
if the Server passed back List<KV>.  Would save on Result instantiation and creation
(and duplication) of a row in constructor (maybe getRow could be lazy.... don't create one
unless its called).

Put some spaces in here so its more readable:

{code}
+  public SortedMap<byte[],SortedMap<byte[],SortedMap<Long,byte[]>>> getMap()
{
{code}

Seems a pity creating a TreeMap when usual case is single family.   Later we can optimize
and only create the TreeMap on addition of second family?

Whats this:

{code}
+  /**
+   * Returns a {@link RowResult}.
+   * @return a RowResult
+   */
+  public RowResult rowResult() {
+    return new RowResult();
+  //  return RowResult.createRowResult(kvs);
+  }
{code}

The below could be written as: "return this.kvs == null || this.kvs.length == 0;"

{code}
+    if(this.kvs == null || this.kvs.length == 0) {
+      return true;
+    }
+    return false;
{code}

Fix these: "+    for(int i=0; i<length; i++) " -- add spaces.

Lots of common code.  Common base abstract class?

These should be static defines rather than created on each construction.

{code}
+    this.minStamp = Bytes.toBytes(0L);
+    this.maxStamp = Bytes.toBytes(Long.MAX_VALUE);
{code}

Regards TimeRange, are we for sure that most compares of timestamps are byte [] rather than
long?  This class is written for byte [].  Surely compare of two longs is faster than creation
of byte array representation and then byte compare?

These should be made on TimeRange creation?  Or at least cached?

{code}
+    long min = Bytes.toLong(minStamp);
{code}

Above is minor.  In general this TimeRange byte [] compare of longs seems like an optimization
that'd never register its so small?

More to follow.



> 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: Jonathan Gray
>            Priority: Blocker
>             Fix For: 0.20.0
>
>         Attachments: hbase-1304-v1.patch, HBASE-1304-v2.patch, HBASE-1304-v3.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.


Mime
View raw message