tl;dr
- Rich Hickey describes datomic as a system which implicitly deals with timestamps associated with data storage
- from my experience, data is often imperfectly stored in systems, and on many occasions needs to retroactively be corrected (ie, often the question of “was a True on Tuesday at 12:00pm?” will have an incorrect answer stored in the database)
This seems like a spot where the abstractions behind datomic might break – do they? If they don’t, how does the system handle such corrections?
Rich Hickey, in several of his talks, justifies the creation of datomic, and explains its benefits.
His work, if I understand correctly, is motivated by core the insight that humans, when speaking about data and facts, implicitly associate some of the related context into their work(a date-time). By pushing the work required to manage the implicit date-time component of context into the database, he’s created a system which is both much easier to understand, and much easier to program. This turns out to be relevant to most database programmers in practice – his work saves everyone a lot of time managing complex, hard to produce/debug/fix, time queries.
However, especially in large databases, data is often damaged/incorrect (maybe it was not input correctly, maybe it eroded over time, etc…). While most database updates are insertions of new facts, and should indeed be treated that way, a non-trivial subset of the work required to manage time-queries has to do with retroactive updates.
I have yet to see any documentation which explains how such corrections, or retroactive updates, are handled by datomic; from my experience, they are a non-trivial (and incredibly difficult to deal with) subset of time-related data manipulation that database programmers are faced with.
Does datomic gracefully handle such updates? If so, how?
2
The question the built in time stamp will answer is what did I believe on Tuesday at 12, not what do I now believe the value to be on Tuesday at 12. If you need a time stamp to tell you when something is true then the time stamp is data, not metadata. Datomic’s built in time stamp is metadata, and should be treated as such. If you later decide that it should really only be true at 1 instead of 12, then you write an update like you would for any other database. Datomic will remember both the new time and when you updated it.
Basically treat the built in time stamp like you would an audit log. It should more or less have zero to do with your application’s day to day logic. A couple of scenarios where it might be useful is if you need to undo a bad write or run an analysis how quickly a value is changing.
1
This is to respond to blueberryfields’ comment @ Oct 3 ’13 at 4:28
The question the built in time stamp will answer is what did I enter on Tuesday at 12, not what do I now believe the entered value to be on Tuesday at 12.
I believe this is how you should use Datomic. The built in time stamp can help you know when a bad input was made so you can make a correction to it. Not to correct what you thought in the past.