Datomic / datascript parity features?
abrooks opened this issue · comments
@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:
- Schema. Specifically :db/cardinality & :db/unique. These would impact transactions (upsert) the most.
- [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.
- 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.
- 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.
I'm nearly done with the functionality but am finding that a good number of the tests are written against specific internal state rather than properties across functionality. This makes the tests very rigid and likely to need to be rewritten when functionality is added (as is the current case).
Before I go re-vamping the tests, are you unlikely to accept pull requests that convert these overly specific tests to ones that test the desired outcomes at a property level?
I'll accept replacement of unit with integration tests.
I added unit tests plenty more to have them function as documentation for newcomers.
In the long run integration tests are more valuable since they change less.
@clyfe Sorry this has taken so long. Projects with other priorities put this on the back burner for a while... Recently, however, I have implemented a number of the above features and am working my way through building up some test coverage.
Are you still interested in receiving these features?
Features welcomed.