Closed cswendrowski closed 7 months ago
I'm +-0 on the first two, as discovering first and last key is cheap, and it's convenient indeed. However it's also simple and infrequently desired enough that it could live in userland.
-1 to the third method, because it means a full table scan and in many scenarios where you need something like leveldb (have a lot of data) isn't actually what you want to do
Agree with @juliangruber on the first two.
Not sure I understand the third method. Can you give an example?
I imagine it's something like https://github.com/juliangruber/level-exists/blob/master/index.js
Let's assume that's the case (shouldn't require iteration though). That's covered by https://github.com/Level/community/issues/106 so I'll close this.
While we're contributing, we were wondering if you had any interest in any of the following quality of life methods we've added to our wrapper for ClassicLevel:
1)
compactFull
- Convenience function that discovers the first and last key and callscompactRange
2)size
- Convenience function that discovers the first and last key and callsapproximateSize
3)has
- Definitely a feature that would be better if it existed upstream, but iterates keys until specified key is discovered (if at all)