Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> HBase wire compatibility


Copy link to this message
-
Re: HBase wire compatibility
Given the +1s, let's do the meetup at:

Tuesday Feb 21st @ 1:00 PM - 3:00 PM
Cloudera Palo Alto
210 Portage Ave,
Palo Alto, CA 94306
Let me know if you have any questions about getting here, etc.

@Ted: I prefer 1 pm because people already agreed to it and it gives us
more time if people want to stay later for more discussion or coding.  You
are certainly welcome to join us late.

Greg

On Thu, Feb 16, 2012 at 2:41 PM, Jacques <[EMAIL PROTECTED]> wrote:

> Fair enough.  That's why I mentioned ByteString more than anything else.
>  If the new RPC will always convert client api/application values into
> ByteStrings and my application is always storing protobuf keys and protobuf
> objects, it'd be nice if I could just hand you a ByteString as the value
> for each of these rather than converting them back to byte[] and then
> having you convert them again.
>
> thanks,
> Jacques
>
> On Thu, Feb 16, 2012 at 2:33 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Feb 16, 2012 at 2:27 PM, Jacques <[EMAIL PROTECTED]> wrote:
> > > Or at a minimum, it would be nice that if
> > > we wanted to get access to the lower level pb objects, that
> modifications
> > > to HTable and/or supporting classes wouldn't be super complicated.
> >
> > It's less a matter of complexity, and more a matter of not wanting to
> > expose the implementation details as part of the API. It really
> > restricts us when we do this -- for example, KeyValue is used in the
> > underlying storage all the way up through the client API, which means
> > it's verify difficult for us to do something like switch to an
> > off-heap storage for cell data, for example.
> >
> > That said, the request for an easy way to build convenience APIs with
> > low numbers of copies makes sense
> >
> > -Todd
> > --
> > Todd Lipcon
> > Software Engineer, Cloudera
> >
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB