Add `db.getMany(keys)` across the board

[Vincent Weevers]

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

• level-supports: Level/supports#11 (2.0.1)
• abstract-leveldown: Level/abstract-leveldown#381 (7.2.0)
• leveldown: Level/leveldown#787 (6.1.0)
• memdown: Level/memdown#212 (6.1.0)
• level-js: Level/level-js#214 (6.1.0)
• deferred-leveldown: Level/deferred-leveldown#89 (7.0.0)
• encoding-down: Level/encoding-down#102 (7.1.0)
• levelup: Level/levelup#725 (5.1.0)
• subleveldown: Level/subleveldown#107 (6.0.0)
• multileveldown: Level/multileveldown@ff1ba48 (5.0.0)
• level-party: 5.1.0
• level-mem: 6.0.0
• level: Level/level#207
• rocksdb: Level/rocksdb#184 (5.2.0)
• level-rocksdb: just docs I moved this remaining item to Level/level-rocksdb#75

[Meirion Hughes]

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.

[Vincent Weevers]

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.

[Evan]

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?

[Vincent Weevers]

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.

[Meirion Hughes]

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.

[Evan]

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

[Sebastian Stammler]

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

[Bonaventure00916]

Disappointed 😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭