@mikerod Regarding datalog syntax for Clara: Would you want it to be schema based? The implementation I have only enforces a datomic schema’s cardinality and uniqueness … nothing related to types. It enables upsert behavior, which may or may not be desirable for Clara users. Cardinality and uniqueness indices are checked and updated before inserting or retracting facts (within the insert/retract functions), and if anything should be upserted then the appropriate retracts and inserts are made. Only one to one facts are indexed at this time, since there’s no uniqueness or cardinality enforcement that applies to one to many. Overall I tried to follow Datomic’s semantics on this: https://docs.datomic.com/on-prem/schema.html#operational-schema-attributes, https://docs.datomic.com/on-prem/schema.html#required-schema-attributes. If a fact is not mentioned in a schema it defaults to one to one cardinality. I think that could be changed easily if you wanted…the idea there was facts are typically one to one for UI and we didn’t want to force users type out cardinality for every fact.

This would affect the implementation at the session-ish level. None of this has to be part of a LocalSession and I don’t think it should be, but I’m toying with a LocalDatalogSession that takes a LocalSession and “indexes” argument so the indexes can travel with a session. It should be possible to use with insert/retract per the normal api (`(-> session (insert facts) (fire-rules))`) though the insert/retract functions would need be datalog specific (`(clara.rules.datalog/insert)`) if enforcing a schema the way I described