Fork me on GitHub
#datomic
<
2016-07-07
>
bhagany01:07:22

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.

marshall02:07:02

@bhagany: I would have to spend

marshall02:07:12

Argh. Phone keyboard

marshall02:07:09

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

marshall02:07:47

@bhagany: ^ I'll see if I can get something that works tomorrow

bhagany02:07:20

@marshall: okay, thanks for the direction. I'll play around with that too.

marshall17:07:26

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

marshall17:07:26

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.

bhagany18:07:19

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

bhagany18:07:33

Thanks for looking into it

marshall18:07:53

Ah. gotcha. Sure. Happy to help if I can

marshall18:07:57

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

marshall18:07:29

then you could still parameterize the query with the parent node IDs, but the rule could take care of all the ref type stuff

bhagany18:07:16

Yes, it's a small fixed set of refs... that's a good idea.

timgilbert20:07:39

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

eraserhd21:07:17

So, I think I discovered there’s no way to recursively pull all attributes, right? I have to specify individual ones.

currentoor21:07:41

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.

currentoor21:07:51

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.

currentoor21:07:16

Any suggestions?

ckarlsen22:07:15

re. "Datomic supports 2.0.X and 2.1.X versions of Cassandra." - does this imply that datomic does not support the latest versions?