hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Smith (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HBASE-2051) Use builder pattern to improve usability of client API
Date Thu, 17 Dec 2009 02:32:18 GMT

     [ https://issues.apache.org/jira/browse/HBASE-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Paul Smith updated HBASE-2051:
------------------------------

    Attachment: aconex-hbase-utils.zip

I have attached a simple Maven project that we use here as a starting point for discussion.
 This won't compile anywhere else because it requires our internal Nexus repository, but someone
with a little Maven experience could tweak this to remove the Parent POM definition and I
think it should work.  It currently depends only on Spring and Google Collections (both ASL
2 licensed).

No test cases as yet sorry, this project was put together as part of a week long hackathon
project as I experimented with HBase.  I'm already an Apache member (psmith@apache.org) so
can potentially be used as a basis for a more formal contribution if need be, but I'm sure
there's lots to discuss with those more intimately familiar with day 2 day HBase coding. 
I could well be naive here, but this works for me and I find the code much more readable when
using this.

> Use builder pattern to improve usability of client API
> ------------------------------------------------------
>
>                 Key: HBASE-2051
>                 URL: https://issues.apache.org/jira/browse/HBASE-2051
>             Project: Hadoop HBase
>          Issue Type: Improvement
>            Reporter: Andrew Purtell
>             Fix For: 0.21.0
>
>         Attachments: aconex-hbase-utils.zip
>
>
> From Paul Smith up on hbase-user@:
> {quote}
> I think a good collection of useful builders and utilities that handle the 80% case will
help HBase gain much more traction.  As an person starting with HBase, there are a lot of
concepts to get, Bytes definitely get in the way of seeing the real underlying patterns. 
I'm a total believer in understanding the internals to get the best out of a product, but
that often comes after experimentation, and these high-level libraries grease the wheels for
faster 'grok'ing the concepts.
> Thinking out loud here, but something like this may be useful:
> {code}
> PutBuilder builder = new PutBuilder(hTable);
> // first Row
> builder.withRowKey(1stRowKey).withColumnFamily("foo")
>     .put("columnA", valueA)
>     .put("columnB",valueB);
> // secondRow
> builder.withRowKey(2ndRowKey).withColumnFamily("eek")
>     .put("columnC", valueC)
>     .put("columnD",valueD);
> ..
> builder.putAll();
> {code}
> {quote}
> Perhaps we could use the Builder pattern to achieve simplification (e.g. HBASE-1990)
and API support for multicalls (HBASE-1986, HBASE-1845) at the same time. Method variants
should accept byte[] or String for keys or values, and lists. 

-- 
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