You can get a diff on any key prefix, much like db.watch().
This also exposes another API function, db.snapshot(), which captures the feedID/seq tuples at the point in time that it's called. I'm not sure whether this is the optimal way to expose this (maybe db.put() could return a snapshot each time?). This function is probably the least well thought out.
My motivation for this was thinking about building views or indexes on top of a hyperdb, not unlike hyperlog-index or flumeview-level.
This is a basic implementation, and has caveats:
Results are accumulated and then written to the stream after a full diff. I bet this can be done smarter and emitted in realtime.
All diffs are between a snapshot and HEAD (now). It would be nice if you could pass in two snapshots via an opts or something.
Live streaming would be great! Right now it's from two static, well-defined points in time.
An API that lets you compare the current state of a hyperdb to an earlier state. For example:
outputs
You can get a diff on any key prefix, much like
db.watch()
.This also exposes another API function,
db.snapshot()
, which captures the feedID/seq tuples at the point in time that it's called. I'm not sure whether this is the optimal way to expose this (maybedb.put()
could return a snapshot each time?). This function is probably the least well thought out.My motivation for this was thinking about building views or indexes on top of a hyperdb, not unlike
hyperlog-index
orflumeview-level
.This is a basic implementation, and has caveats:
opts
or something.Cheers! :tada: