Fork me on GitHub

@nooga are you using 5530?




@haywood for things like ~name, you can use query inputs


for the dynamic pull expressions, I think you do have to make it programmatically, but you can minimize the variable area by using a map data structure


Note that you can also use datomic.api/pull-many


That's actually the best approach for your problem IMO.


you’ll need to quote that datalog vector 🙂


@jaret I’m running datomic-free-0.9.5407


@nooga Can you post your transaction data ?


@marshall sure, give me few minutes


If we have an entity with, let’s say five possible string values (about 5-10 letters), like an enum, should we model the type as string or ref (having another entity with the accepted values)? We use the pull syntax a lot, so having an extra entity doesn’t add much complexity when reading, but to have a string is simpler and more readable, but the other approach feels a little bit more solid. Pros and cons as always.


@teng Sounds like a use case for Enums like described in the schema documentation: So basically you create entities with db/ident. This makes Pull API return them as values (and the Peer caches them).


@ovan I played around with that, but it didn’t help us much actually (the way you use enums in Datomic). Firstly it was storing an id (referring to an Enum entity) any way, so it actually did things harder than to store them as a “real” entity, so I changed back from enums actually. It is nice to use enums in scripts and so (improved readability) but when sending them to client systems (and back again), then it made things harder in my opinion.


@teng you get benefits when you want to e.g. find all things with enum value 1


because it’s an entity you can walk references from


@robert-stuttaford ok, I'll give it a second try 🙂


@limix the slack channels are for specific questions that can be answered in a sentence or two, I'll send you a DM about getting started on your journey 🙂


I agree with @teng, we found :db/ident values to be more of a hassle than a help because they just resolve to {:db/id 23} in pull requests. We went back to just using :db.type/keyword for our user roles and related small groups of enums


I have a query that retrieves all users, pretty much this:

(d/q '[:find [(pull ?u [:db/id
                        :fifteen.more/attributes]) ...]
       :in $
       [?u :crm.user/email]]
The query is simple and returns only 70,000 results, but it takes >500 seconds to complete.


The time is in a cold peer but excludes DynamoDB connection time.


The query is running on a peer inside an aws data center, so latency to dynamodb is low. It's the kind of query that mysql would return in a second or so.


This is an ETL job by the way. Any ways to improve the performance?

Matt Butler18:12:15

I have a query where I only want to return a single solution per entity, in short all solutions for a single entity get unified into a single return value. I have been using the collection find spec to do this [entity …] which seems to work great, is this the correct way to do what i want? However this doesn’t work anymore when I want to return multiple values/variables from a query, is there a way do this?

[:find [(pull ?entity) ...]
                   :where (QUERY LOGIC)]

[:find (pull ?entity) ?someothervar
                   :where (QUERY LOGIC)]


@mbutler, what would you want the query to return?

Matt Butler19:12:52

@pesterhazy a unique list of entities (in this case users) that satisfy the datalog (but also in this case the a variable from that datalog) [user var] would work

Matt Butler19:12:15

at the moment if a user satisfies the datalog in multiple cases (due to a cardinality many relationship) then 2 results will get returned for that user ?user1 ?someothervar1 and ?user1 ?someothervar2

Matt Butler19:12:59

Is the answer just use group-by or something outside of datomic to unify the results under a single user?