On Sun, Aug 12, 2012 at 8:11 PM, Ed Kohlwey <[email protected]> wrote: > I really like this. I've thought for some time that something of this sort > should be part of the Accumulo core API. The inconsistent use use > CharSequence, String, Text, and byte[] objects to represent the n-tuples > gets very old very quickly, and distracts programmers in a multitude of > ways. > > The current API should really be refactored to make CharSequence, Text, > byte[], and ByteBuffer types available for setting the contents of Key and > Value types just for consistency's sake. It would be nice to have something > like this added as well.
I made TypoMutation extend Mutation. I wanted to make TypoKey extend Key, but could not because the return types conflicted. This could be done, but getRow(),etc would need different names. > > It would be good to see this package use nio-ish strategies to reduce the > load on the garbage collector, by using buffer classes instead of arrays. > But otherwise the design looks solid. I would definitely like to avoid allocations if possible, I will look into that. > > On Fri, Aug 10, 2012 at 8:07 PM, Keith Turner <[email protected]> wrote: > >> I put together a simple abstraction layer for Accumulo that makes it >> easier to read and write Java objects to Accumulo key and value >> fields. The data written to Accumulo sort correctly >> lexicographically. >> >> I put the code on github and would like some feedback on the design >> and whether it should be included with Accumulo. >> >> https://github.com/keith-turner/typo >> >> Its still a little rough and I need to add encoder for all of the >> primitive types. >> >> Keith >>
