Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> Generic Supertypes/Pluggable Client


Copy link to this message
-
Re: Generic Supertypes/Pluggable Client
On Fri, Jul 5, 2013 at 10:33 AM, Ed Kohlwey <[EMAIL PROTECTED]> wrote:

> > Just a knee-jerk reaction here, but allowing a user to provide Text,
> String
> > or byte[] is painful?
> >
> > I've always viewed it as String if I want to be lazy, and byte[] or Text
> > when I'm more concerned about performance and don't want to be making new
> > objects for every record I need insert into Accumulo.
>
>
> The problem isn't that people are allowed to provide different types, the
> problem is that the types are inconsistent. Value still has only one
> method

to get data out, which is get() and returns a byte array. Key has the
> option of Text or ByteSequence, neither of which are easily compatible with
> CharSequence. CharSequence, Text, or byte[] are allowed as parameters to
> Range. Scanner.fetchColumn() is only for Text, unless you use the version
> that takes a Column but that is also very inelegant. Every single
>

It would be very nice if the types you mentioned were more consistent
across the API.  Personally I would like to see byte[] and ByteSequence
fully supported across all of the APIs related to reading and writing data.
  We added support for byte[] to mutation in 1.5. Thinking back, we should
have added support for ByteSequence too.
> application I've worked on with Accumulo has a utility class with methods
> to help convert between these types, and then also the application's own
> data model. The application code is always unnecessarily inelegant and
> confusing to new people on the project. Explaining the necessity of the
> (frankly bizarre) type conversion scaffold always makes programmers who are
> new to the platform make a stinkface and ask why it is still written the
> way it is.
>