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. >
