Fork me on GitHub
#datomic
<
2016-06-22
>
bhagany17:06:14

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.

bkamphaus23:06:22

@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.

bhagany23:06:49

@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.

bhagany23:06:09

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

bkamphaus23:06:35

@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).

bkamphaus23:06:12

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.