accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <>
Subject Re: Generic Supertypes/Pluggable Client
Date Fri, 05 Jul 2013 16:40:15 GMT
On Fri, Jul 5, 2013 at 10:33 AM, Ed Kohlwey <> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message