support reverse iteration (iterator->Prev())

[GoogleCodeExporter]

it would be nice to have a reverse keyword argument to the 
RangeIter so that when reverse=True iterator->Prev() is used
in place of iterator->Next()

Original issue reported on code.google.com by Paolo.Losi on 18 Oct 2011 at 9:13

[GoogleCodeExporter]

Sure.

Original comment by arnim...@gmail.com on 18 Oct 2011 at 10:00

• Changed state: Accepted

[GoogleCodeExporter]

Latest commit does seem to do the job.

This is a bit hairy, e.g. when the upper limit is out of bounds, the iterator 
becomes invalid, and you have to create a new one, and SeekToLast() on that one.

Any critique of the API is of course welcome.

Original comment by arnim...@gmail.com on 19 Oct 2011 at 12:11

• Changed state: Fixed

[GoogleCodeExporter]

Thanks for the speedy feedback!

Just a couple of comments on the API:

* I'd really s/is_reversed/reversed/ 
  It's quite popular in python (e.g. sorted([], reverse=True)
* I'd swap the semantics of from_key and to_key in case.
  of is_reverse=True. See the modified tests for the proposed semantics:

        s = ''.join(k for k, v in db.RangeIter('M', 'J', is_reverse = True))
        self.assertEquals(s, 'MLKJ')

as far as the SeekToLast() issue, I'm trying to understand if the asymmetry in
py-leveldb implementation for is_reverse=True/False is because of leveldb
or it's something not really justified.

Thanks again!!!

Original comment by Paolo.Losi on 19 Oct 2011 at 9:26

[GoogleCodeExporter]

as far as SeekToLast. see:

http://code.google.com/p/leveldb/issues/detail?id=47

Original comment by Paolo.Losi on 19 Oct 2011 at 9:40

[GoogleCodeExporter]

leveldb authors have suggested exactly what you have implemented :-)

just a couple of notes:

- you reinstantiate a new iterator object before SeekToLast().
  Is that required at all?
- there are some debugging printfs ...

I think I'm done. Thank you for the very useful binding...

Original comment by Paolo.Losi on 19 Oct 2011 at 7:56

[GoogleCodeExporter]

I assumed that at that point the iterator became invalid, and not recoverable. 
This is simpler.

I´m gonna keep the semantics for key_from and key_to for now. I like to think 
of it as defining a closed range of keys, with a lower and upper limit, and you 
can either iterate it forwards or backwards.

Original comment by arnim...@gmail.com on 19 Oct 2011 at 11:00

[GoogleCodeExporter]

Thanks again!

Original comment by Paolo.Losi on 20 Oct 2011 at 12:56