HBase
  1. HBase
  2. HBASE-2051

Use builder pattern to improve usability of client API

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      From Paul Smith up on hbase-user@:

      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:

      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();
      

      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.

        Issue Links

          Activity

          Hide
          Paul Smith added a comment -

          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.

          Show
          Paul Smith added a comment - 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.
          Hide
          stack added a comment -

          Code looks good. Couple of comments wouldn't go amiss (smile). How you think this addition would be distributed Paul? You think the Builder pattern would be in hbase or a distinct project? I suppose life would be easier if hbase+hadoop were all up in a maven repo somewhere?

          Show
          stack added a comment - Code looks good. Couple of comments wouldn't go amiss (smile). How you think this addition would be distributed Paul? You think the Builder pattern would be in hbase or a distinct project? I suppose life would be easier if hbase+hadoop were all up in a maven repo somewhere?
          Hide
          Paul Smith added a comment -

          Yeah comments could definitely be added, hopefully the code is self-documenting in most ways, but always good to add some more, obviously test cases would be essential.

          Personally I think this sort of pattern has high value within HBase itself and would (hopefully) lend to more people being able to get up to speed quicker with Hbase. The critical issue is this project's current dependency set (Spring and Google Collections). While both ASL licensed, adding dependencies in a project can be controversial.

          Ideally yes, Hadoop and Hbase final versions should be in the Maven repo, I'm really not sure why it's not published, that would really help, I can't imagine that's very hard ..?

          I don't mind starting this of in Google Code (has advantage of quicker release cycle), but that may inhibit overall usage and development as well. happy to discuss further.

          Show
          Paul Smith added a comment - Yeah comments could definitely be added, hopefully the code is self-documenting in most ways, but always good to add some more, obviously test cases would be essential. Personally I think this sort of pattern has high value within HBase itself and would (hopefully) lend to more people being able to get up to speed quicker with Hbase. The critical issue is this project's current dependency set (Spring and Google Collections). While both ASL licensed, adding dependencies in a project can be controversial. Ideally yes, Hadoop and Hbase final versions should be in the Maven repo, I'm really not sure why it's not published, that would really help, I can't imagine that's very hard ..? I don't mind starting this of in Google Code (has advantage of quicker release cycle), but that may inhibit overall usage and development as well. happy to discuss further.
          Hide
          stack added a comment -

          In the code you have so far, the Spring dependency looks like it could be undone since only used in one place for minor benefit (least as I read it). In general, we've not prob. adding new jars when tit makes life easier(all additions are minor hiding in the shadow of the fat jruby complete jar).

          Anything that makes hbase easier to use, we're game for.

          We're a bit behind but its looking like hadoop jars wil be up in apache maven repo. before too long. HBase should follow suit.

          I think the google code route a good way to go at first at least. I'd suggest you talk up your progress over in hbase-dev to keep your work in the spotlight – it might help you get recruits whether users or co-devs.

          Thanks.

          Show
          stack added a comment - In the code you have so far, the Spring dependency looks like it could be undone since only used in one place for minor benefit (least as I read it). In general, we've not prob. adding new jars when tit makes life easier(all additions are minor hiding in the shadow of the fat jruby complete jar). Anything that makes hbase easier to use, we're game for. We're a bit behind but its looking like hadoop jars wil be up in apache maven repo. before too long. HBase should follow suit. I think the google code route a good way to go at first at least. I'd suggest you talk up your progress over in hbase-dev to keep your work in the spotlight – it might help you get recruits whether users or co-devs. Thanks.
          Hide
          Paul Smith added a comment -

          Thanks, I'll push this to Google Code and publish the details on hbase-dev.

          Show
          Paul Smith added a comment - Thanks, I'll push this to Google Code and publish the details on hbase-dev.
          Hide
          Karthik K added a comment -
          Thanks, I'll push this to Google Code and publish the details on hbase-dev.

          If this is already here - may be - can you help with the url here. These utils definitely seems interesting, from an dev acceptance/ evangelism perspective.

          If this is not already available yet - it might be worth to put up at some DVCS , like git or Hg . But that might be just me.

          Show
          Karthik K added a comment - Thanks, I'll push this to Google Code and publish the details on hbase-dev. If this is already here - may be - can you help with the url here. These utils definitely seems interesting, from an dev acceptance/ evangelism perspective. If this is not already available yet - it might be worth to put up at some DVCS , like git or Hg . But that might be just me.
          Hide
          stack added a comment -

          Moved from 0.21 to 0.22 just after merge of old 0.20 branch into TRUNK.

          Show
          stack added a comment - Moved from 0.21 to 0.22 just after merge of old 0.20 branch into TRUNK.
          Hide
          Paul Smith added a comment -

          For the interested reader, I have made a GitHub project over here:

          http://github.com/tallpsmith/hbase-utils

          still those unit tests to add, but I've pushed the original changes over there with a package name change to reflect the common pattern we use for open-sourcing stuff within Aconex.

          Show
          Paul Smith added a comment - For the interested reader, I have made a GitHub project over here: http://github.com/tallpsmith/hbase-utils still those unit tests to add, but I've pushed the original changes over there with a package name change to reflect the common pattern we use for open-sourcing stuff within Aconex.
          Hide
          stack added a comment -

          Moving out of 0.92.0. Pull it back in if you think different.

          Show
          stack added a comment - Moving out of 0.92.0. Pull it back in if you think different.
          Hide
          Andrew Purtell added a comment -

          Addressed elsewhere, but not fully. Could reopen if there is active interest (aka a patch soon forthcoming)

          Show
          Andrew Purtell added a comment - Addressed elsewhere, but not fully. Could reopen if there is active interest (aka a patch soon forthcoming)

            People

            • Assignee:
              Unassigned
              Reporter:
              Andrew Purtell
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development