search

dat-ecosystem-archive / DEPs

Dat Enhancement Proposals. Contains all specs for the Dat protocol, including drafts. [ DEPRECATED - see https://github.com/hypercore-protocol/hypercore-proposals for similar functionality. More info on active projects and modules at https://dat-ecosystem.org/ ]
https://dat-ecosystem.github.io/DEPs
166 stars 17 forks source link

For Discussion: timestamps in hyperdb #11

Open bnewbold opened 6 years ago

bnewbold commented 6 years ago

Rendered pre-merge

Proposes including "event" timestamps at the hyperdb abstraction layer for every change to the database.

I suspect @mafintosh would prefer doing this at the highest abstraction level as possible (eg, at hyperdrive, not hyperdb or hypercore), but i'm curious what others think, and whether this would be valuable at all.

Before seriously reviewing to merge as Draft, I would want to demonstrate working code and have a better idea what the API would look like, but this is otherwise pretty flushed out.

pfrazee commented 6 years ago

I dont have much to say except I'm +1 the premise and my gut reaction is that hyperdb is the right place for this (not hypercore).

bnewbold commented 6 years ago

This got discussed here: https://github.com/mafintosh/hyperdb/issues/97#issuecomment-387048934

With the new hyperdb deleted flag, even a deletion node can contain a value. This means that a higher-level application can include a timestamp in every hyperdb value/node.

I still think a timestamp might be "special" enough of a form of metadata to be included in the hyperdb Entry protobuf schema as an optional field, but I don't feel particularly urgent about it. Going to let this DEP PR linger, but wouldn't oppose closing it if we do a garbage collection at some point.

pfrazee commented 6 years ago

I'd like to have the timestamps personally, but I don't have a pressing need for it yet.

martinheidegger commented 5 years ago

Referencing: https://github.com/mafintosh/append-tree/issues/16