Datomic - db / isComponent equivalent to foreign key constraint?

Question

In the Datomic Schema doco - they mention a schema attribute called db/isComponent . This seems to apply to relationships defined by :db.type/ref .

db/isComponent not used in the Seattle example. Is it fair to say that the :db.type/ref relationships are not applied in Datomic (to use the relational database foreign key dependency concepts) - unless you set them using db/isComponent ?

Answer 1

Containment Relations ( :db.type/ref + :db/isComponent )

:db/isComponent used to indicate containment relationships, i.e. composition relationships from UML. You can think of it as a "relation A B. "A striking example is the model part of a simple blog:

In Datomic, if you use the :db/isComponent as part of the Article-Comments relationship above, retracting the article will also cancel all of its comments. For a complete code example, consider Datomic: a containment relationship, i.e. db / isComponent .

Note in Datomic there is nothing that would prevent the wrong type of object from being added to the attribute :db.type/ref . In the above example, Datomic will allow you to add a link to the Author object (instead of a comment) without much care. This means that foreign key constraints come into play.

Foreign key constraints ( :db.type/ref + database functions)

Datomic defines the relationship using the attribute :db.type/ref , but actually does nothing. To use arbitrary foreign key constraints, you should use the database functions instead.

In the Seattle database that you are referring to, the attributes :community/orgtype should only refer to a few valid enum values ​​( :community.orgtype/* ), but there is actually no execution at runtime:

To show how arbitrary foreign key constraints can be implemented in Datomic, I wrote a database function (called add-fk ) that prevents the value of an invalid enum from being bound to attributes :community/orgtype .

For a complete code example, consider Datomic: database functions and foreign key constraints . For example, the behavior of the add-fk database function is shown below:

  ;; will succeed [[:db/add #db/id [:db.part/user] :community/name "15th Ave Community"] [:add-fk #db/id [:db.part/user] :community/orgtype :community.orgtype/personal]]) ;; will fail [[:db/add #db/id [:db.part/user] :community/name "15th Ave Community"] [:add-fk #db/id [:db.part/user] :community/orgtype :community.type/email-list]]) ;; java.lang.Exception: :community.type/email-list is not one of ;; [[:community.orgtype/community], [:community.orgtype/commercial], ;; [:community.orgtype/personal], [:community.orgtype/nonprofit]] 

Answer 2

Not. In Datomic, db / isComposite refers to composition (as opposed to aggregation ) in the sense of OOP / UML.

If db / isComposite is set to true when you remove the object, all subcomponents are also removed. When you touch an object, all of its subcomponent objects will touch recursively.

Consider two different examples of relationships from the world of e-commerce:

1) Client ---- UserPreferences

This is usually a composition. The lifetime of the Preferences entities depends on the user's lifespan. In Datomic userPreferences ref on Customer must have the db / isComposite attribute set to true.

2) Customer ---- OrderItem

This is usually aggregation. OrderItem may exist even when the Client is deleted. This is the default type of ref in Datomic.

The relational model implements both dependencies as foreign keys, so in terms of presentation, the answer is: yes, db / isComponent can be represented in the RDBMS as a relational constraint (FOREIGN KEY) with the CASCADE action, but conceptually this is not equivalent.