This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-22
Channels
- # beginners (8)
- # boot (41)
- # cider (1)
- # cljsrn (2)
- # clojure (91)
- # clojure-dev (34)
- # clojure-gamedev (3)
- # clojure-germany (6)
- # clojure-greece (324)
- # clojure-japan (2)
- # clojure-miami (4)
- # clojure-nl (6)
- # clojure-quebec (3)
- # clojure-russia (26)
- # clojure-spec (50)
- # clojure-uk (19)
- # clojurescript (147)
- # core-async (5)
- # css (2)
- # cursive (15)
- # datascript (7)
- # datomic (6)
- # hoplon (1)
- # jobs (4)
- # lein-figwheel (17)
- # off-topic (4)
- # om (52)
- # om-next (10)
- # onyx (1)
- # planck (19)
- # proton (1)
- # re-frame (81)
- # reagent (61)
- # spacemacs (1)
- # specter (46)
- # spirituality-ethics (7)
- # untangled (7)
- # yada (17)
I made a terrible assumption about :where
clauses pruning the results of pull
in a query. I'm now pretty sure the only way to prune pull
is to use a filtered db, which I can't do because REST api, and probably would be a bad idea in this case anyway. However, I'm throwing this out there before I engage in a large refactor, in case anyone has an idea off the top of their heads that I haven't thought of.
@bhagany: afaik pull
doesn’t work in query via the REST api, though if you use it with a find spec you can sometimes nest it just so that the normal collection logic for sets of tuples will return something anyways.
@bkamphaus: pull
in query via REST is my primary way of using query. I do it like [:find [(pull ?e [*])] …]
. My only complaint in this area is that [:find (pull ?e [*]) . ...]
(the scalar find spec) returns a vector of lists, instead of a map.
not entirely sure I've explained my problem well, but in any case, I'm still pretty confident I'll have to go through with my big refactor
@marshall (or someone at Cognitect, not there any longer) can speak more definitively about the status of pull in the REST API, but if it’s the issue I remember, the behavior you’re seeing is falling out of an implementation detail and not explicitly defined or promised (i.e. you should flat out receive an error doing a scalar find spec w/o the pull expression), it just so happens that those forms fall into the same abstract collection shape as a set of tuples (as the REST API is designed to support).
either way I’m not entirely sure what you mean by the :where
clause pruning results, anything not matched in :where
shouldn’t be expanded into a map via pull.