This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-10-15
Channels
- # admin-announcements (1)
- # announcements (11)
- # asami (6)
- # aws (26)
- # babashka (17)
- # beginners (119)
- # bristol-clojurians (7)
- # chlorine-clover (2)
- # cider (3)
- # circleci (1)
- # clj-kondo (10)
- # clojure (127)
- # clojure-australia (3)
- # clojure-dusseldorf (5)
- # clojure-europe (135)
- # clojure-france (5)
- # clojure-nl (8)
- # clojure-uk (6)
- # clojurescript (103)
- # clojurewerkz (1)
- # css (2)
- # cursive (5)
- # datalog (5)
- # datomic (36)
- # emacs (3)
- # events (2)
- # figwheel-main (3)
- # fulcro (1)
- # graalvm (3)
- # helix (31)
- # jobs-discuss (4)
- # leiningen (1)
- # london-clojurians (1)
- # malli (17)
- # off-topic (2)
- # parinfer (10)
- # portal (1)
- # re-frame (48)
- # reitit (2)
- # reveal (12)
- # shadow-cljs (3)
- # sql (3)
- # tools-deps (4)
- # vim (4)
- # xtdb (22)
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
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).
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