It would be a third API surface. We have the main database API surface which is roughly equal to that of a sublevel, and would now add another API surface which only has read methods, e.g. db.snapshot().get(). If 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 write methods and thus 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-based approach, you can pass a snapshot to multiple sublevels, which cleanly solves the main use case of retrieving data from an index (see example).
I renamed the existing snapshot mechanism to "implicit snapshots" and attempted to clarify the behavior of those as well.
Several related issues can be closed, because this PR:
This is a documentation-only PR, acting as an RFC. I opted for a token-based approach (as suggested by Rod Vagg in https://github.com/Level/community/issues/45) instead of a dedicated snapshot API surface (as suggested by @juliangruber in https://github.com/Level/community/issues/47). Main reasons for not choosing the latter:
db.snapshot().get(). If 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 write methods and thus transactions as well, which I consider to be out of scope although transactions are in fact a use case of snapshots.db.sublevel().snapshot().get(key)read from the snapshot but also prefix the given key. By instead doingdb.sublevel().get(key, { snapshot }), the sublevel can just forward that snapshot option to its parent database.I renamed the existing snapshot mechanism to "implicit snapshots" and attempted to clarify the behavior of those as well.
Several related issues can be closed, because this PR: