plugin extension points: merge level-hooks / level-sublevel

[dominictarr]

I'm not suggesting we do this right away, but I am suggesting this is something worth considering.

Also, I don't want to merge this, unless there is a consensus that this is an easy and effective way to build plugins.

I'd also intend to refactor the code style, etc, to match levelup.

I think that given these base features, and maybe one or two more,
a wide array of plugins could be developed.

[dominictarr]

I realize that this could be construed as going against the modularity principle, but I think this may be worthwile, because A) we already have the core separated into leveldown B) this would provide a firm standard basis for more modularity.

Also, I don't want to suggest we merge immediately, but we should put it on the table.

[juliangruber]

those 2 plugins you suggest to go into core will be crucial for the future development of levelUp.

With hooks multilevel will work with more plugins or e.g. a middleware layer can easily be implemented.

SubLevel will come in handy when we decide to give each plugin its own meta db.

[dominictarr]

see also #97

[vweevers]

@ralphtheninja I think a new issue is in order (in community perhaps), because the hooks of level-sublevel are a powerful concept, and we don't have a replacement atm.

[ralphtheninja]

I can re-open and move to community.

[vweevers]

One part of this (sublevels) is code complete: Level/abstract-level#8. As for hooks, let's define some requirements:

1. They don't have to support range options like level-hooks did, because sublevels are builtin
2. For the same reason, we don't need post hooks. For that you can use events of a sublevel
3. They should support promises
4. They should support adding operations (to a batch). This is the main use case IMO.
5. To start simple, execute hooks sequentially (not in parallel like level-hooksdown).
6. If a db.batch(..) calls contains operations with a sublevel property, execute the hooks of that sublevel, instead of hooks of the db? TBD.

High-level, I see three ways to implement hooks:

1. As an abstract-level layer (similar to level-hooksdown).
   • Downside: hooks would receive already-encoded keys and values. Unless we override public methods - e.g. put() instead of _put() - but I'd really like to avoid that pattern.
2. Builtin to abstract-level, and executed before encoding (of keys and values) and prefixing (of sublevel keys).
   • Gotta take performance into account. If one or more hooks are present, put() and del() should internally use a batch(). Initially we can do that eagerly, later on perhaps only if one of the hooks wants to add operations.
3. Builtin to abstract-level, and executed after encoding and before prefixing.
   • I don't see a use case for this

[vweevers]

cc @bcomnes as the author of level-hooksdown: if hooks were builtin, which features are a must for you?

[bcomnes]

Let me think about ideas for a bit. The only reason I wrote hookdown was to better support hooks and indexes when working with sub level downs at the time.

Areas for simplification should definitely be welcomed (eg if only pre or post hooks can do the job of both, why have the other). Simplifying the order hooks run in (series) is also probably a better api for community plugins in order to clarify behavior when various hooks are combined in unanticipated ways. You can always combine actions to run in parallel in a single hook. I believe this option was added mainly because I wasn't sure what the best approach was at the time.

So +1 to those changes if the functionality can be built in.