Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add
db.keys()
, .values()
, iterator.nextv()
and .all()
I'm squeezing this in for similar reasons as #8. I wondered whether these additions would be breaking. The short answer is no. In addition, adding this now means `level-read-stream` can make use of it without conditional code paths based on `db.supports.*`. Ref Level/abstract-leveldown#380 Adds key and value iterators: `db.keys()` and `db.values()`. As a replacement for levelup's `db.create{Key,Value}Stream()`. Example: ``` for await (const key of db.keys({ gte: 'a' }) { console.log(key) } ``` Adds two new methods to all three types of iterators: `nextv()` for getting many items (entries, keys or values) in one call and `all()` for getting all (remaining) items. These methods have functional but suboptimal defaults: `all()` falls back to repeatedly calling `nextv()` and that in turn falls back to `next()`. Example: ``` const values = await db.values({ limit: 10 }).all() ``` Adds a lot of new code, with unfortunately some duplicate code because I wanted to avoid mixins and other forms of complexity, which means key and value iterators use classes that are separate from preexisting iterators. For example, a method like `_seek()` must now be implemented on three classes: `AbstractIterator`, `AbstractKeyIterator` and `AbstractValueIterator`. This (small?) problem extends to implementations and their subclasses, if they choose to override key and value iterators to improve performance. On the flip side, the new methods are supported across the board: on sublevels, with encodings, with deferred open, and fully functional. This may demonstrate one of the major benefits of `abstract-level` over `abstract-leveldown` paired with `levelup`. Yet todo: - [ ] Tests - [ ] Replace use of `level-concat-iterator` in existing tests - [ ] After that, try another approach with a `mode` property on iterators, that is one of entries, keys or values (moving logic to if-branches... I already don't like it but it may result in cleaner logic downstream).
- Loading branch information