Hi, All.
I'm curious what the best practices are around persisting complex
types/data in Accumulo (and aggregating on fields within them).
Let's say I have (row, column family, column qualifier, value):
A foo MyHugeAvroObject(count=2)
A foo MyHugeAvroObject(count=3)
Let's say MyHugeAvroObject
Hi Mike!
The Combiner interface is only for aggregating keys within a single row.
You can probably get away with implementing your combining logic in a
WrappingIterator that reads across all the rows in a given tablet.
To do some combine/fold/reduce operation, Accumulo needs the input type to
be
For a bit of psuedocode, I'd probably make a class that did something akin
to: http://pastebin.com/pKqAeeCR
I wrote that up real quick in a text editor-- it won't compile or anything,
but should point you in the right direction.
On Mon, Jul 14, 2014 at 3:44 PM, William Slacum
Thanks, William. I was just hitting you up for an example :)
I adapted your pseudocode (http://pastebin.com/ufPJq0g3), but noticed that
this.source in your example didn't have visibility. Did I worked around
it correctly?
When I add my iterator to my table and run scan from the shell, it returns
Ah, an artifact of me just willy nilly writing an iterator :) Any reference
to `this.source` should be replaced with `this.getSource()`. In `next()`,
your workaround ends up calling `this.hasTop()` as the while loop
condition. It will always return false because two lines up we set
`top_key` to
Hmm...Still doesn't return anything from the shell.
http://pastebin.com/ndRhspf8
Any thoughts? What's the best way to debug these?
On Mon, Jul 14, 2014 at 5:14 PM, William Slacum
wilhelm.von.cl...@accumulo.net wrote:
Ah, an artifact of me just willy nilly writing an iterator :) Any
A quick sanity check is to make sure you have data in the table and that
you can read the data without your iterator (I've thought I had a bug
because I didn't have proper visibilities more times than I'd like to
admit).
Alternatively, you can also enable remote-debugging via Eclipse into the
Anything in your Tserver log? I think you should just rethrow that
IOExcepton on your source's next() method, since they're usually not
recoverable (ie, just make Counter#next throw IOException)
On Mon, Jul 14, 2014 at 5:48 PM, Josh Elser josh.el...@gmail.com wrote:
A quick sanity check is to
