Fork me on GitHub
Leaf Garland13:03:02

In this from last year, there is an example pull call like so:

(d/pull (d/db conn) '[:user/type] [:user/id "a"])
=> #:user{:type #:db{:id 87960930222153, :ident :user.type/a}}
The returned value for :user/type has the :db/id and the :db/ident. When I run a similar pull, I only get the :db/id. If I want the :db/ident value then I have to put it in the pull pattern explicitly. My schema is very similar to the enumerations example in datomic docs. Any ideas why I don't see the :db/ident key/value in my returned map?


PRobably in this example :user/type was a :db/isComponent true


when you don’t specify what to retrieve from a ref attribute (i.e. you did [:user/type] not [{:user/type [:my/attr]}], what happens depends on the isComponent-ness of the attribute


if not isComponent, you will only get :db/id


if isComponent, it’s the same as *


my recommendation: always specify what you want from your refs

Leaf Garland20:03:14

Thanks. Agreed about specifying the attributes. I was curious about the difference in results.

Kris C09:03:19

How do you use :xform if the pull exp is like this [{:user/type [:my/attr]}]?

Kris C13:03:37

@U09R86PA4 any hint on this ^^?

Joshua Suskalo16:03:41

With datomic on-prem, what is the return type of custom aggregation functions? The one example that I have found is in the docs and returns a single value for making an aggregate that returns only 1 item, but how does this work when the aggregation function wants to return N items? And if the answer is simply to return a sequence, how does datomic keep track of the order of the items? I would assume it can't be metadata since not all types that datomic can store can have metadata.


> And if the answer is simply to return a sequence, how does datomic keep track of the order of the items?


Not sure what you mean here: results are unordered anyway

Joshua Suskalo16:03:23

results may be unordered, but the results from an aggregation may be tied to other values, in e.g. this query:

[:find ?title (max n ?year)
 :in $ n
 :where [?entity :movie/year ?year]
        [?entity :movie/title ?title]]


max is already getting a group of years which share a ?title

Joshua Suskalo16:03:19

Oh, then maybe I have misunderstood how exactly this works. My understanding was that it would attempt to take the top n title/year pairs based on the year.

Joshua Suskalo16:03:43

Hmm. Is there a way to do this?


typically you’d return all results and then sort


if that’s not an option, a custom aggregate which accepts a tuple of all results and does the sort and top-n inside of it


or redesign the schema to expose what you want to sort by as an index


(composite tuple)


if you’re on on-prem, there is no overhead to sorting all results outside the query--that data was literally all just fetched in your peer anyway, and the full result set already made, so nothing is saved by pushing that work into the query


for client api, sometimes that result went over a wire, so yeah, it would be nice to reduce the result size before returning it

Joshua Suskalo16:03:46

right, that makes sense.

Ben Hammond20:03:34

Hi. Is it possible to specify a txInstant value directly within a pullspec? I know that my entity was transacted in a oner (but I suppose datomic cannot assume that...)


No. You can add a ref to the tx entity on your domain entity though.

Ben Hammond20:03:52

oh? How would I do that?

Ben Hammond20:03:51

I mean; can I do that within the single call to (d/transact ?

Ben Hammond20:03:23

or do I have to make a second transaction to poke the tx ref into the domain entity?


"datomic.tx" is the tempid of the current transaction, so yes, like this [:db/add my-entity :ref-to-tx "datomic.tx"]

😗 1
Ben Hammond20:03:00

perfect. thankyou

Ben Hammond20:03:59

well. I'm too lazy to put an explicit timestamp into my domain entity


Tread carefully. I feel like most uses of the tx entity for domain info are better suited to be modeled with attributes under your control.

Ben Hammond20:03:10

so I am hoping to get a timestamp for free

Ben Hammond20:03:37

yeah you are prolly right; I might live to regret this mightnt I

✔️ 1

yeah, that’s iffy