Add db.getMany(keys) across the board

[vweevers]

Background: Level/abstract-leveldown#380 and Level/levelup#491.

• level-supports: Add features: getMany, keyIterator, valueIterator, iteratorNextv, iteratorAll supports#11 (2.0.1)
• abstract-leveldown: Add db.getMany(keys) abstract-leveldown#381 (7.2.0)
• leveldown: Add db.getMany(keys) leveldown#787 (6.1.0)
• memdown: Add db.getMany(keys) memdown#212 (6.1.0)
• level-js: Add db.getMany(keys) level-js#214 (6.1.0)
• deferred-leveldown: Add db.getMany(keys) deferred-leveldown#89 (7.0.0)
• encoding-down: Add db.getMany(keys) encoding-down#102 (7.1.0)
• levelup: Add db.getMany(keys) levelup#725 (5.1.0)
• subleveldown: Add db.getMany(keys) subleveldown#107 (6.0.0)
• multileveldown: Level/multileveldown@ff1ba48 (5.0.0)
• level-party: 5.1.0
• level-mem: 6.0.0
• level: Document new features level#207
• rocksdb: Add db.getMany(keys) rocksdb#184 (5.2.0)
• level-rocksdb: just docs I moved this remaining item to Sync README with level level-rocksdb#75

[MeirionHughes]

I'll try with the rockdb port to help out if no one was already doing it. I also need to check the typings on DT as they're broken after the 'default' export removals. So I'll start adding getMany at same time.

[vweevers]

Go for it, thanks! Note that on rocksdb we must first port Level/leveldown#783, Level/leveldown#784, Level/leveldown#785 (in that order), and then Level/leveldown#787.

[gogoout]

I'll try with the rockdb port to help out if no one was already doing it. I also need to check the typings on DT as they're broken after the 'default' export removals. So I'll start adding getMany at same time.

Just asking, do you plan to use the rocksdb's native getMany interface to implementing this?

[vweevers]

I would prefer that we don't, because it will increase the code diff between leveldown and rocksdb, making cherry-picking commits from one to the other more work. In addition, the leveldown code is written in anticipation of additional features like iterator.all() which will reuse common functions.

[MeirionHughes]

Just asking, do you plan to use the rocksdb's native getMany interface to implementing this?

That is what I was looking to do...

I would prefer that we don't, because it will increase the code diff between leveldown and rocksdb

... but I guess not. :D

I don't think I know enough to do it tbh: the low-hanging method I was targetting to call:

  virtual std::vector<Status> MultiGet(const ReadOptions& options,
                                       const std::vector<Slice>& keys,
                                       std::vector<std::string>* values) {

has the comment:

Consistent Get of many keys across column families without the need
for an explicit snapshot. NOTE: the implementation of this MultiGet API
does not have the performance benefits of the void-returning MultiGet
functions.

So:

• a) the Worker is doing options_.snapshot = database->NewSnapshot(); and I'm not sure if (as per comment) whether this will be used. and
• b) that bar basic reduction in cross-domain calls, that there would actually be performance benefit of changing it to rocksdb's native MultiGet unless it also handles passing through column_family handles.

Probably makes sense to just do all cherry picking for now.

[gogoout]

@vweevers @MeirionHughes Just confirming anyone of you are going to implementing this for rocksdb? Just eager to try the new interface :)

[sebastianst]

Types are still missing getMany. Opened an issue in the levelup repo.