Great talk, one key point to note though - datomic creators suggest the term accumulate-only, not append-only, to describe datomic. The docs state "Datomic is not an append-only system, and does not have the performance characteristics associated with append-only systems". It does give you a lot more out-of-the-box leverage as a database, though...
I'd be curious to know how Eventum faired regarding what is mentioned around 42:40 in the video. Specifically, the idea that datomic manages the time aspect of a domain for you. That seems to be a potential trap because the time aspect "managed for you" (via transaction time and hence history) cannot be updated later. That is, if domain time means to you time you can update, then the transaction time is not a place to store domain times. I'm not saying eventum got this wrong, they may well have understood it well, from what is on the video, but from reading around it is something that a few people have tripped up on when first encountering datomic so seems worth special care. Long story short, if you need times that you are going to want to change, you shouldn't think datomic's history feature will solve that for you with no effort. The history feature is only for when the database came to know about a fact, and to reflect that semantic, those times *cannot* be updated later (= the transaction log itself cannot be reordered). So it seems perhaps more helpful to think of the history feature as an extra thing that picks up where your modelling left off, rather than "managing (domain) time for you". So, so long this is fully understood, there isn't a problem. But for a casual user who expects the same freedom an update in place database gives (for those "timestamps" - they're not ordinary timestamps), it can come as a shock. A very sharp tool, study well before use! Full disclosure, I'm currently only two months into using & designing with datomic, so should not be considered an authority on this.
I agree. Datomic is by default unitemporal. To get bitemporality one needs to design their data to accomodate that, typically with a time period accociated with facts.
