I like pull in theory because it clearly separates the point at which data is fetched from the processing logic. With entity as I understand it any attribute access may end up doing i/o. That said my colleagues have pushed for using entity pretty much everywhere, which makes things really convenient and hasn't caused any issues. So... I think I'm fine with entity alone
Thanks for that feedback. 🙂
I'm not currently an Asami user, so feel free to ignore, but I find the Datomic pull API a must-have feature in my day-to-day work. This is definitely a biased view, since the same syntax is used to define data-fetching on the frontend (Fulcro components), apis (EQL), and backend (Pathom and Datomic). Pathom and EQL has really highlighted the power of the pull syntax, as I can easily support other kinds of storage engines (e.g. SQL dbs, KV dbs, and HTTP apis) without changing the language-franca of the system. It's a nice cherry on top if the query engine just supports the pull syntax directly. 😉 For me the killer feature of the pull-syntax is that it separates data-filtering from data-pulling [sic]. The data-filtering is often complicated enough it needs to be written as code anyways, but the data-pulling can be written and manipulated as a data structure (makes it easy to serialize, allow/forbid keys, do various kinds of clojure.walk term-rewriting, safely accept and sanitize from outside users, etc).
Hmmm, OK
To be honest, when it was first introduced in Datomic I already had code that did something similar, and I didn’t see the need to go back and refactor everything to start using it. As a result, I haven’t really used the Pull API very much at all, and don’t know the full extent of it
Likewise I'm not an Asami user, but we added eql/project
to Crux to essentially serve the same function as pull
in the find
vector. The EQL library made it pretty straightforward to add the basic functionality in ~30 LoC (discounting other changes/additions to plumbing, and we've yet to support recursion or unions) https://github.com/edn-query-language/eql see the PR: https://github.com/juxt/crux/commit/ea3fdf0e1fe333333f7864410153579b3df8434d#diff-a7f71cb84b0cd65bf523b004c963e402c6882fe573ae214ecc2d2efb7501bf47R1244-R1274
I think being declarative is a major part of what makes Datalog great, and pull/EQL just extends the declarative-ness further