This is a good tutorial, but there are a few misconceptions / mistakes: > Avoid nils > > Datomic does not support nil values for attributes. When y

This is a good tutorial, but there are a few misconceptions / mistakes: > Avoid nils > > Datomic does not support nil values for attributes. When you do not have a value for an attribute, you should either skip it or pass an empty value: a zero, an empty string, etc. That’s why the most of expressions have (or "") at the end of threading macro. Datomic doesn't support `nil` on purpose: since it's a fact database, the correct approach is to not assert the attribute (iow, just omit it). Since the schema is a property of the database (not the entity), this makes your database forward-compatible to any new fact that you may need to store without having to be explicit about the past. You can also use `(missing? ?entity :attribute)` on queries, which should do a faster lookup on the EAVT index vs. checking for sentinel values. > JSON data > > In Datomic, there is no JSON type for attributes. I’m not sure I made a proper decision, but I just put those JSON data into a text attribute. Sure, where is no a way to access separate fields in a datalog query or apply roles to them. But at least I can restore the data then selecting a single entity: You can flatten a JSON object into a namespaced map. At this point you get what is essentially an entity w/ well named attributes that you can transact and query against. Since the schema is flexible and doesn't require migrations, in theory you can support even arbitrary objects that you don't know the schema in advance by inspecting the deserialized object. --- Datomic is a beast different enough to require some learning on what is optimal/idiomatic in terms of data modelling, because the paradigm shifts from appending/mutating tuples over multiple tables to asserting/retracting facts on what is essentially "one big table" (entity, attribute, value, transaction).