TLDR: thumbs up if you agree that deferring operations is only useful while the db is opening.

I'm working on getMany(). Which is a new abstract-leveldown and levelup method that gives abstract-leveldown the responsibility of checking whether the db is open when getMany() is called. As an experiment for Level/community#58. But I'm running into an inconsistency that's particularly problematic in subleveldown (which has to deal with two instances of deferred-leveldown and levelup, and is a test bed for API parity).

deferred-leveldown and levelup are inconsistent in their deferredOpen behavior: the former allows operations while the db has any status, the latter only if 'opening' or 'open'. For example, if the status is 'closed', deferred-leveldown will put operations in its queue. But in practice we don't get there because levelup will yield a new ReadError('Database is not open').

@ralphtheninja @juliangruber Given that the order of initialization in levelup is:

• Wrap input db with deferred-leveldown
• Start opening it (changing its status from 'new' to 'opening')
• Start accepting operations (after returning from constructor)

I propose the following changes:

• deferred-leveldown will only defer operations if the status of its underlying db is 'opening'
• Otherwise it will yield new Error('Database is not open').

This is a breaking change for deferred-leveldown, but semver-patch for levelup.

See also Level/levelup#710 (comment).