At the moment, this is a documentation-only PR, acting as an RFC. In particular I'd like review of my choice to use a token-based approach (as first suggested by Rod Vagg in Level/community#45) as opposed to a dedicated snapshot API surface (as suggested by Julian Gruber in Level/community#47). Main reasons for not choosing the latter: - It would be a third API surface. We have the main database API, the sublevel API which is equal to that except for implementation- specific additional methods, and would now add another API which only has read methods (get, iterator, etc, but not put and batch). If the API was reusable, meaning you could pass around a snapshot as if it was a regular database (like you can with sublevels) then I'd be cool with it. But for that to happen, we'd have to implement transactions as well, which I consider to be out of scope although transactions are in fact a use case of snapshots. - It would have a higher complexity once you factor in sublevels. I.e. to make `db.sublevel().snapshot().get(key)` read from the snapshot but also prefix the given key. By instead doing `db.sublevel().get(key, { snapshot })`, the sublevel can just forward that snapshot option to its parent database. - Furthermore, with the token approach, you can pass a snapshot to multiple sublevels, which cleanly solves the main use case of retrieving data from an index (I included an example in the docs). I renamed the existing snapshot mechanism to "implicit snapshots" and attempted to clarify the behavior of those as well. If accepted, some related issues can be closed, because this PR: - Includes (a more complete write-up than) Level/classic-level#40. - Mentions Level/leveldown#796 (which should be moved rather than closed). - Answers Level/classic-level#28. - Solves the main use case as described in Level/leveldown#486. - Effectively completes Level/awesome#19.

Uh oh!

Document snapshots #19

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions