This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-23
Channels
- # admin-announcements (2)
- # arachne (2)
- # beginners (76)
- # boot (241)
- # cider (14)
- # cljsrn (2)
- # clojars (3)
- # clojure (94)
- # clojure-android (12)
- # clojure-dev (33)
- # clojure-gamedev (1)
- # clojure-greece (3)
- # clojure-india (1)
- # clojure-nl (2)
- # clojure-quebec (3)
- # clojure-russia (21)
- # clojure-spec (38)
- # clojure-uk (72)
- # clojurescript (62)
- # cursive (20)
- # datascript (3)
- # datomic (14)
- # devcards (1)
- # dirac (14)
- # emacs (11)
- # hoplon (7)
- # jobs (2)
- # keechma (1)
- # lein-figwheel (9)
- # leiningen (9)
- # luminus (1)
- # off-topic (6)
- # om (13)
- # onyx (30)
- # planck (181)
- # proton (3)
- # re-frame (6)
- # reagent (6)
- # specter (108)
- # spirituality-ethics (7)
- # untangled (3)
there is of course the (expected) divergence in behavior that pull
will omit fields not matched but keep the entities, whereas where
clauses must all unify (i.e. if an attribute is specified but missing the entity won’t be included in the results).
@bkamphaus: ah, I was just doing [*]
as the pull expression as convenient shorthand, I don't believe I've ever actually done it that way. My pull expressions are all fairly long and nested.
re: what I'm expecting, perhaps an example would suffice. Given 3 entities with this shape: {:db/id 1 :children [{:db/id 2 :attr :foo} {:db/id 3 :attr :bar}]}
, I was trying to write a query like [:find [(pull ?e [:db/id :attr])] :in $ ?e :where [?e :children ?child] [?child :attr :bar]]
my actual situation is more complex than this, and it was easier to not test this than it looks 🙂
Not sure I follow why that's your expectation, ?e will only match the first entity, and won't have :attr so it would return the ID for 1 and omit any key/value for :attr (is that what you see?) -- a nested pull spec could retrieve the child but won't limit to the child you intend to retrieve, assuming that's what you mean by pruning.
right. when I say it was a "terrible assumption", I mean, it was really stupid and doesn't hold up to even the most cursory thought experiment.
Query at present will limit results to parents that have a child with a bar Val for attr, but pull will retrieve anything it can.
Can refactor to tuples though, you can still get [e child child-attr-val] shaped results
I will give that some thought. I'm dealing with some decently long graph traversals with my pull expressions though, and that makes it seem more prohibitive than refactoring without a bad assumption
Hmm, yeah that's a fairly tough shaped problem. Non-trivial graph traversal via included rest API functionality I mean. I would probably reach for rules though i haven't used any with rest API calls before. Rules are just edn Params though I'm not sure if there are any hiccups there.
I've used them with REST without issue… I don't think I'm grokking how they'd apply here, but it's been a long day
Without knowing the nontrivial expansion of your graph I'm just thinking of something like the mbrainz sample rules https://github.com/Datomic/mbrainz-sample/blob/master/resources/rules.edn