Fork me on GitHub
Ben Kamphaus00:06:37

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]]


and then expecting only entities 1 and 3 to be returned by the pull


my actual situation is more complex than this, and it was easier to not test this than it looks 🙂

Ben Kamphaus00:06:41

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.


very focused on whether there are other ways to recover from my blunder

Ben Kamphaus00:06:16

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.

Ben Kamphaus00:06:07

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

Ben Kamphaus00:06:34

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

Ben Kamphaus00:06:22

Without knowing the nontrivial expansion of your graph I'm just thinking of something like the mbrainz sample rules