On 7/5/13 12:40 PM, Keith Turner wrote:
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.
I would agree that it's desirable to have the same set of argument types
across the entire client API.
However, this is an entirely separate subject than getting typed values
back out of Accumulo. Personally, I think this makes much more sense as
an addition around the Accumulo client API, as there's absolutely
nothing that *needs* to change in the Accumulo API to support this.
Unless the implementation filters down to the tabletservers to perform
this transformation (which opens up an entirely new can of worms), I
think I'd rather see such an API live on top of Accumulo's and people
can use said API instead of the regular client API.
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.
