This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-07
Channels
- # admin-announcements (2)
- # boot (111)
- # capetown (5)
- # cider (15)
- # clara (15)
- # cljs-dev (8)
- # clojure (78)
- # clojure-brasil (1)
- # clojure-dev (2)
- # clojure-greece (25)
- # clojure-hk (1)
- # clojure-russia (5)
- # clojure-seattle (1)
- # clojure-spec (120)
- # clojure-sweden (3)
- # clojure-uk (63)
- # clojurescript (161)
- # data-science (1)
- # datomic (21)
- # editors (43)
- # emacs (3)
- # funcool (1)
- # hoplon (72)
- # instaparse (11)
- # jobs (1)
- # off-topic (2)
- # om (212)
- # onyx (9)
- # other-languages (129)
- # proton (5)
- # re-frame (15)
- # reagent (18)
- # slack-help (4)
- # spacemacs (18)
- # untangled (224)
- # yada (21)
My data model is a digraph in which some children can have multiple parents, with multiple ref attributes linking parents to children, depending on the kind of parent. I'd like to write a query that takes parent eids and returns all the nodes that are children of the complete set of the parents. I could do this if I could pass in only a tuple of parent-ids, but since I also need to pass in ref attributes for each parent, I am not sure how to do it. Something like:
[:find ?child
:in $ [[?parent-id ?parent-ref] ...]
:where [?parent-id ?parent-ref ?child]]
except that will pull back children of any of the parents, whereas I want children of all of the parents. I'm hoping I've missed something.I think you can accomplish that with a rule that resolves the parent relationship via the specified attribute but I'd have to play with it a bit to be sure
@bhagany: I thought a bit more about your question. The reason you’re getting the behavior you’re seeing is that using the collection binding form (…) will run the query on each element of the collection (your [id ref] tuples) individually and return the union of those results. If you need to join across elements, they should be provided in the same tuple to the query. There are a couple options for your particular problem. Are you generating these queries dynamically? If so, I’d recommend just generating them entirely programmatically with each parent/reftype relation as its own datalog clause (i.e. [?parentA :ref/typeA ?child] [?parentB :ref/typeB ?child]).
Also, if you’re fully generating them, there’s not any need to parameterize the parentA and parentB in that example - you can simply generate the query with the entityIDs of those elements in place.
@marshall: I started out fully generating them, which I can still do. But I'm using the rest api, so it basically comes down to string interpolation, and I was hoping to avoid all that :). I'll stick with that until I manage to get this written in clojure.
Another thought/question - do you have a fairly small set of ref types and are they mostly fixed? if so, you could hand write a rule to handle them and that might make things easier
then you could still parameterize the query with the parent node IDs, but the rule could take care of all the ref type stuff
Hey all... just curious, is anybody using https://hub.docker.com/r/pointslope/datomic-pro-starter/ in production? Seems a lot simpler than manually setting my transactors up directly on ec2 instances, but I'd be curious about other people's experiences
So, I think I discovered there’s no way to recursively pull all attributes, right? I have to specify individual ones.
In our app we've got some attributes in client side queries that are not actually retrievable with the pul API. For example the query [:dashboard/title :dashboard/created-at]
title
works with datomic.api/pull
but created-at
is derived with a query over the :db/txInstant
.
Ideally we'd like to have an extensible pull wrapper where we could specify custom ways to query keys like :dashboard/created-at
but the results get merged back in such that it looks like a regular pull API call.
Any suggestions?