When iterating over multiple versions of the same key, is there a way to
receive them in chronological order rather than last inserted first?

For example, if I insert

aKey cf1 cq1 10 aValue1
aKey cf1 cq1 20 aValue2
aKey cf1 cq1 30 aValue3

When scanning I receive them in reverse timestamp order - which is great
for retrieving the most recent version

aKey cf1 cq1 30 aValue3
aKey cf1 cq1 20 aValue2
aKey cf1 cq1 10 aValue1

If I'd like to "replay" history, should I basically grab the whole list and
then invert it, or is there a built in way to do this?

Thanks!

Mike

Mike,

See https://issues.apache.org/jira/browse/ACCUMULO-803

There's some chatter about whether or not this will be included in the
1.5.0 release. I'd encourage you to leave some feedback on the ticket in
the positive if you'd like this more "natively" supported.

On 02/15/2013 06:05 PM, Mike Hugo wrote:
> When iterating over multiple versions of the same key, is there a way to
> receive them in chronological order rather than last inserted first?
>
> For example, if I insert
>
> aKey cf1 cq1 10 aValue1
> aKey cf1 cq1 20 aValue2
> aKey cf1 cq1 30 aValue3
>
> When scanning I receive them in reverse timestamp order - which is great
> for retrieving the most recent version
>
> aKey cf1 cq1 30 aValue3
> aKey cf1 cq1 20 aValue2
> aKey cf1 cq1 10 aValue1
>
> If I'd like to "replay" history, should I basically grab the whole list
> and then invert it, or is there a built in way to do this?
>
> Thanks!
>
> Mike
>

Mike,

There is no built in way to do this. If you are replaying history more often than you are grabbing the latest version, you may consider time-stamping the keys yourself with MAX_LONG - current system time in your ingest client.

If you want to grab the whole list and resort, the WholeRowIterator makes it easy to grab a whole rows worth of data at once, assuming your rows fit in memory.

Sent from my iPad

On Feb 15, 2013, at 6:05 PM, Mike Hugo <[EMAIL PROTECTED]> wrote:

> When iterating over multiple versions of the same key, is there a way to receive them in chronological order rather than last inserted first?
>
> For example, if I insert
>
> aKey cf1 cq1 10 aValue1
> aKey cf1 cq1 20 aValue2
> aKey cf1 cq1 30 aValue3
>
> When scanning I receive them in reverse timestamp order - which is great for retrieving the most recent version
>
> aKey cf1 cq1 30 aValue3
> aKey cf1 cq1 20 aValue2
> aKey cf1 cq1 10 aValue1
>
> If I'd like to "replay" history, should I basically grab the whole list and then invert it, or is there a built in way to do this?
>
> Thanks!
>
> Mike
>

On a related note, it would be cool to have the ability to reverse the
sorting order completely, basically reading the map files in reverse. There
might be some issues with iterator to make data 'look' right but it would
be cool to be able to scan back and fourth on tables while generating
visualizations, etc.
On Feb 15, 2013 7:38 PM, "Aaron Cordova" <[EMAIL PROTECTED]> wrote:

> Mike,
>
> There is no built in way to do this. If you are replaying history more
> often than you are grabbing the latest version, you may consider
> time-stamping the keys yourself with MAX_LONG - current system time in your
> ingest client.
>
> If you want to grab the whole list and resort, the WholeRowIterator makes
> it easy to grab a whole rows worth of data at once, assuming your rows fit
> in memory.
>
> Sent from my iPad
>
> On Feb 15, 2013, at 6:05 PM, Mike Hugo <[EMAIL PROTECTED]> wrote:
>
> > When iterating over multiple versions of the same key, is there a way to
> receive them in chronological order rather than last inserted first?
> >
> > For example, if I insert
> >
> > aKey cf1 cq1 10 aValue1
> > aKey cf1 cq1 20 aValue2
> > aKey cf1 cq1 30 aValue3
> >
> > When scanning I receive them in reverse timestamp order - which is great
> for retrieving the most recent version
> >
> > aKey cf1 cq1 30 aValue3
> > aKey cf1 cq1 20 aValue2
> > aKey cf1 cq1 10 aValue1
> >
> > If I'd like to "replay" history, should I basically grab the whole list
> and then invert it, or is there a built in way to do this?
> >
> > Thanks!
> >
> > Mike
> >
>