Get range

[kesla]

So, this is pretty cool.

I've implemented the getRange-method (#98) without chaning any C++!

I'm building this upon the PR using abstract-leveldown (#50), since the arguments checking then is done in javascript-land and therefore I can implement this in pure js-land!

[juliangruber]

sweet, lgtm!

[heapwolf]

nice!

[rvagg]

without changing any C++!

which begs the question: does it belong in LevelDOWN at all then?

discuss

[juliangruber]

it belongs in leveldown when this eventually gets part of abstract leveldown. if anything, the buffering iterator should make it

[rvagg]

Buffering iterator makes perfect sense, the range get though isn't so clear-cut since it's something that can be done with an addon. I certainly don't think it's a clear candidate for abstractleveldown either as it's far more than a primitive. It's just something that a data store can expose if it makes sense.

[kesla]

I think of the .binding property in this PR as not part of the public leveldown-api (perhaps is should be _binding rather than binding) and without using that a getRange-addon can't be written.

If we implemented the buffering iterator without regards to compatibility with the existing leveldown-compatible backends, we could have a public next method that returns an array of data, and then implement getRange in userland using that.

[heapwolf]

FWIW, this is possibly one of the most requested features from people I talk to.

[kesla]

I've updated https://github.com/kesla/level-get-range to work with #91 - so from that point of view this PR isn't really needed. I'm calling the iterator.binding directly when available

[kesla]

... and here's streams that outputs arrays (the buffered arrays) of data https://github.com/kesla/level-buffered-streams - so I guess that it's feasible to fullfill some of the use cases in userland.