3 ms·
Without schema-on-write, the A in EAVT has no meaning. A tells us nothing about V. That makes it basically impossible for declarative systems like Hyperfiddle t
by dustingetz 6y ago
Without schema-on-write, the A in EAVT has no meaning. A tells us nothing about V. That makes it basically impossible for declarative systems like Hyperfiddle to understand your data structures and auto-generate UIs and such from the attributes. The fourth goal of Datomic is to "enable declarative data programming in applications" [1]. That's the design goal that makes Datomic so interesting to me, and Crux does not share it. Which is fine. Crux have given great reasons for doing things that way.
https://www.infoq.com/articles/Datomic-Information-Model/ https://www.infoq.com/articles/Datomic-Information-Model/
- refset 6y agoWithin Crux's new transaction functions you are able to run queries against the entire database and (very soon) also against speculative transactions, to enforce all manner of constraints and control whether the transactions succeed/fail. Schema-on-write is therefore a matter of funnelling all `put` & `delete` operations through these functions. I suspect someone could even create a library of transaction functions to emulate the entire Datomic data model, if so desired. However, I still believe schema-on-read is more desirable in general though, as you can simply extend a query to only care about the AV combinations which conform to some definition for that A. The Calcite SQL integration we've been building works like this. Conformance could also be processed asynchronously and documents be labelled as "conformed" as/when to reduce the burden during general queries. (also, hey!)