clyfe / clara-eav Goto Github PK

We've put this here, but it really is unrelated to clara-eql. If it works here, I'll make a PR.

https://github.com/eraserhd/clara-eql/blob/develop/src/net/eraserhead/clara_eql/eav_map.clj

Hi,

Thanks a lot for your work!

As you may know there are some other projects which basically doing the same thing: rules engine based on datomic query api and datoms (eav, triples etc).

They are:

• https://github.com/CoNarrative/precept
• https://github.com/arachne-framework/factui

It would be great if you guys can merge your effort and build one datomic based rules engine.
(maybe name it Claromic :) )

And precept can implement only reagent specific part and factui rum specific.

cc @alex-dixon (https://github.com/alex-dixon) @levand (https://github.com/levand)

There is also DataScript and @tonsky (https://github.com/tonsky) just received Clojurist Together support - so he will work on it next couple month. Maybe DataScript can be used as well?

Thanks!

CoNarrative/precept#118

We would like this as a mechanism to aid in debugging - inspecting the session. Zach Tellman's Potemkin has a library that allows easier creation of magic maps, and the eav-map mentioned in #3 would make it nicely feasible.

So, we are probably going to build this regardless. Does it belong here?

@clyfe I've been using CoNarrative/Precept and have struggled enough with some of the design choices to the point that I've decided a re-write is needed — then I found clara-eav! The design choices of attr-as-type, bindable state (vs global mutable state) and use of clojure.spec for DSL parsing/transform are great. I'm wondering if you're interested in adding features that make clara-eav more closely aligned with Datomic/datascript notions (they're different things, clearly, and 1:1 parity is not attainable or desirable).

The features that I'd specifically like to add would include:

1. Schema. Specifically :db/cardinality & :db/unique. These would impact transactions (upsert) the most.
2. [EAVt] tuple shape and transaction entities. I'm not interested in time/history but rather the provenance of facts and being able to provide causal error messages that trace back to the sources is quite interesting for my use cases.
3. Pull features in query. I think this could get quite large but there's some pull features I've wanted and would start with those in a way compatible with fully building out pull. This would also bring in :db/component in the schema.
4. Recursive datalog rules. Forward chaining rules can produce facts in an iterative, eager manner that delivers the equivalent functionality as lazy recursive rules but there are spatial and computational tradeoffs. This is both interesting for rule LHS (which, depending on usage could be forced to be eager) as well as queries (which could be fully lazy).

I've listed the above in order of importance to me. If you're not interested in them or have concerns or thoughts about how the implementations might be done, let me know. If need be, I can fork and, if you find value, you could pull features later.