Fork me on GitHub

Hi, is it possible to attach more than one NodePolicyArn for the Datomic Cloud instances? We hit the Amazon’s (6144 chars) in our current policy and I was looking for a workaround. I would like to hear if anyone hit the same problem before and overcome it.

Tobias Sjögren12:09:02

Anyone knows if the idea of “nested Datoms” has been discussed anywhere?


What do you mean by that?


I think conceptually thats handled by the same structure as transactions


for entity E1 you learn fact F1 has a value of V1


for entity E1 you learn fact F2 has a value of V2


and you learn that in transaction T1

Tobias Sjögren12:09:47

By “nested Datom” I mean that one datom can be the entity (“E” position) of another datom.


What use case are you thinking of? As Ethan said, transactions are meant to cover most of these. Datomic doesn’t support arbitrary reification for any entity value (i.e. like RDF does), but transactions are a reification mechanism over groups of datoms (the transaction data)

Tobias Sjögren13:09:13

For example, to represent this information: “Rich is employed by Cognitect as the chief architect.”

Tobias Sjögren13:09:11

(trying ideas..)


I’m not sure how that would apply?

Tobias Sjögren13:09:17

I guess a Datom essentially can connect two “things” (Entity and Value). When you need to connect more than two things - as in my example: “Rich”, “Cognitect” and ” Chief Architect” are three “things” - it seems to make sense to use nesting.

Tobias Sjögren13:09:51

This nesting is something that the “Associative Model of Data” supports (see my above thread). Also, it seems it is a proposed addition to the RDF standard called “RDF-star”.


I think what you want isn't "nested datoms" - datoms can represent this relationship


xtdb afaik decomposes documents with nested structures into datoms internally


it might be just a way to turn

{:thing {:wow 1}}


into a set of datoms which represent the nesting


What is the advantage over either an entity to represent the relationship or a compound value with two references?


Ie the usual ERD modeling

Tobias Sjögren13:09:46

I’m in the process of trying to find out. How would you express “Rich is employed by Cognitect as the Chief Architect.” as Datoms?


Assuming the point is multiple employers at once: [rich :employment e][e :employer cognitect][e :role chief-architect]. Or even reverse direction of :employment


Same thing I would do in a relational db or a doc db

Tobias Sjögren14:09:56

Which datom states that Rich is the Chief Architect?


[e :role chief-architect], where e is the identity of the employment

Tobias Sjögren14:09:52

I guess using nested datoms, it could be like this (where “xxxx” in the second datom represents the first datom):

[rich :employment cognitect]
[xxxx :role chief-architect]


It’s unclear to me that this is what it would mean. If this were reification, xxx would mean the fact itself is a chief architect, not rich-at-cognitect


This looks like just another way to encode the same thing, and the predicate now has to carry the nuance of what part of the triple is its true object (i.e. is it “adverbial” modifying the fact or is a “meta statement” about the statement itself) . Maybe it’s more compelling in an open system like RDF where you can’t control how people encode things, so you may get stuck needing to annotate a fact instead of an entity. In a closed schema I think I’d rather just not deal with this nuance.

👍 1

Many systems (even in RDF) do add a special-purpose handle (often an extra component to the triple, like ?tx in datomic) to make “higher order” facts expressible. This is a generalization of that, so maybe it will be fine.

👍 1
Tobias Sjögren16:09:19

One more example (in you don’t mind) - how would you express this sentence in datoms?: “Flight BA1234 arrived at Heathrow Airport on 12-Aug-1998 at 10:25am.”


It would depend on what this was for, but a first cut would be three datoms joined by an entity that represents an arrival. In pseudocode, [e :arrival/flight BA1234][e :arrival/airport heathrow][e :arrival/time 12-Aug-1998 10:25am]

👍 1
Tobias Sjögren08:09:41

That makes sense and really helps me in the quest of trying to understand! In “The Associative Model of Data” ( - which seem to a precursor to Datomic that like RDF-star can nest facts - it would be represented like this:


I’m not sure how related they are. Datomic is inspired by rdf’s basic idea of a “triple” expressing a fact, but I think the influence kind of ends there. I think the datom is in the service of finer-grained truth model, and what you call the “nesting” (the transaction-entity annotation) is in service of the epochal time model, not supplying a new way to express domain-model concepts (in fact, over-using datomic datom history for domain-accessible features is a common datomic pitfall In other respects it’s pretty traditional. The world is still closed, multi-valued relationships are still reified, normal entity-relationship modeling process pretty much still applies.

Tobias Sjögren14:09:38

The “Associative Model of Data” (where my screenshot is from) even had immutability 10 years before Datomic - the two seems very similar to me. Would you say the “nesting” wouldn’t help you build Datoms? I don’t quite understand the connection between the transaction and the so called nesting… Thanks for the blog link - are there any more Datomic blogs you would recommend?


> I don’t quite understand the connection between the transaction and the so called nesting… A datom is [E A V TX OP], where TX is the transaction entity the fact is from, and OP is whether this is an addition or retraction of the fact in that TX. So you can treat a datom as a thing “nested” in a transaction because you can join the TX entity to the whole fact. Conceptually [TX :db/add [E A V]], [TX :db/retract [E A V2]]. vs [E A V TX :db/add][E A V2 TX :db/retract] It’s just encoded into the fact itself instead of being a general mechanism.

Tobias Sjögren09:10:18

Which is you can write the datom code as fact additions/retractions nested inside the transaction datom(s)? The effect is still that one or more datoms are connected through a single transaction datom, right?


The datoms are objects not subjects of facts about the transaction. So they’re connected via a transaction entity not transaction datom.


Howdy everyone! Got a slew of announcements for Cloud and Ions:


What does “self-unification within a single clause” mean?


Hi @U083D6HK9! We had a report from a customer that in a very specific use case where they had a self-referencing entity (`:foo/ref`) that the single clause [?e :foo/ref ?e] would return all entities instead of a subset of the entities which matched the clause. This was undefined behavior and so we decided to add a feature that would unify on a single clause. Here is a gist of the previous behavior:

(d/q '[:find (count ?e)
       :in $
       [?e :some/attr ?e]]
     (d/db conn))
;=> [[3]] ;; returns a count of entities where the left ?e is subset of the right ?e (note there are 4 total entities and 1 self referential)


Now this same query should return the single self referential entity and unify on ?e.


Thank you for the thorough explanation. Makes total sense. Interesting use case.


It's definitely an edge case. Adding a second clause for instance gets the desired behaivor... i.e.

(d/q '[:find (count ?e1)
       :in $
       [?e1 :some/attr ?e2]
       [(= ?e1 ?e2)]]
     (d/db conn))

✔️ 1