Fork me on GitHub

hi, how do i find proper ami for datomic in my region? i am trying to use


is datomic peer and transactor bound to specific ami?


@karol.adamiec i suppose you'll need to use the commands on to generate some CFN and copy the AMI out of there


i see that the changelog lists regions that are supported Transactor AMIs are now available in all AWS regions that support DynamoDB: us-east-1, us-west-1, us-west-2, eu-west-1, ap-northeast-1. and ap-southeast-1.


rather new to this so i will have to sum it up to make sure i get it 🙂


peer is not bound to ami, should work with any linux amazon image


transactor needs specific ami image, to find it one chould run aws commands from linked article?


yes. or wait for @marshall or @jaret to point us all to a table of region + ami codes 🙂


you could make some searchs on AWS console to discover the AMI id


there is a new feature on terraform 0.7 to use this as a data-source... I made a proof of concept here and it worked quite well


I planned to port and make a PR to the this recipe, but didn't managed to take the time yet


Hey all, if I’ve got a message entity with a topics attribute which is a ref attribute of cardinality many, and I’ve got a project entity, how can I write a pull pattern that allows me to get all messages where a given project is a topic?


if you want a set of things filtered by some criteria - i.e. the selection for which some constraint holds, you’ll need to use query (pull is projection, essentially)


@bkamphaus I was planning to write the pull inside of a query, not use the pull api directly, does that change anything?


You'll just need to use the pull expression to get the attributes of interest and the where clause to select the entities (projects that are topics).


That makes sense, but what if I want to return a project that includes those very messages where it was reference, kind of like

{:name “My project”
 :messages [{:text “Msg text”}]}


Would that be done as two separate queries that are then merged in clojure-land?


caveat: not tested. Could also just put pull portions in where clause if you’re ok with those limiting results (i.e. don’t need to keep projects in results if no project name or messages in results if messages don’t have text.

[:find (pull ?p [:project/name]) (pull ?m [:message/text])
:in $ ?t
[?p :project/topic ?t]
[?p :project/message ?m]]
inputs: database, topic


@robert-stuttaford @karol.adamiec We do not have a table of regions and AMI codes. Robert’s method of generating CFN and copying the AMI is the way to get the code.


Is this a bug?

dev> (d/q '[:find (pull ?eid [:db/id "*"]) .
       :in $
            [?eid :db/ident :state/CA]]
     (d/db (:core moyo.datomic/db-connections)))
{":db/id" 17592186045434, ":db/ident" :state/CA}

dev> (d/q '[:find (pull ?eid [:db/id *]) .
       :in $
            [?eid :db/ident :state/CA]]
     (d/db (:core moyo.datomic/db-connections)))
#:db{:id 17592186045434, :ident :state/CA}


Specifically, whether or not you pass in "*" or '* changes the type of keys returned by a pull query.


That is by design, I believe. The ”*” version is a convenience for e.g. Java clients


I would imagine that the Java client would handle that kind of translation.


It can, but getting strings back immediately is sometimes desired


Not sure where I got that impression, but my understanding is that ”*” and * have those differing semantics.


I see. Having that happen implicitly depending on the type of * passed in seems like it's an easy way to confuse consumers.


I think it surprised me the first time I saw it.