Gleefully skip – In pretty much any data-based project, you have tables with fields like changed_by_whom, changed_when. Or tables X and X_History. And changed_by_whom is a foreign key, so you can never delete from Who, you instead set deleted=‘Y’ and try to remember to check it in all 937 select statements. This is what I call half-baked. Half-baking takes a ton of work! >> With Datomic, the program can see the context, even the whole world, as of some previous state, at no extra charge. But what about changed_by_whom, chnaged_when? You can add those as attributes of the transaction in Datomic. That’s what I mean by “use the real transaction log instead” of programming your own.
Baesd on stable input – In pretty much any data-based project, procedures sometimes fail because of inputs that do not match up. The system architect imposed structure or exercised discipline to try to provide each procedure with consistent inputs, but compromises are made. The programmer fights a losing battle with failure modes that do not exist in Datomic. >> With Datomic, you write functions-of-a-database-value. All the inputs are there. All are consistent. Do not waste time on rigor of the kind you expected to need when working with other databases.
Consequences – “After changes to entities X, do Y…” Your app does X. That’s enough! Let a second program do Y. Thus, you don’t tangle the program code related to distinct policies, you can restart X without bothering Y, you can run X and Y on separate machines, you can run Y only during the hours when power is cheapest. Now, how will Y know when to take action? >> Datomic’s transaction log is available via API. Y can efficiently “follow along” with the progress made by X.