what’s “the better way” to handle things like aggregation (of values), comparison (of dates), etc. should it be done in the db query? in post-processing code afterward? does it even matter if you’re not using a peer?

in my head i guesstimate that it’s better to not use the db’s resources for such concerns, but that’s probably wrong because 1. you can have as many queriers as you want, so you’re not “clogging up the db process” 2. the data is right there and it’s likely faster for the query engine to handle things like sorting, aggregation, etc.

@lwhorton I don't think there is a one size fits all answer here. In the peer/ions model, db and application share resources so i wouldn't worry about that.

In the peer/ions model, queries compose like code, so for a first pass, i would just do what makes my code simpler. Splitting complex operations into multiple queries that compose together is perfectly idiomatic in the peer/ions model.

Getting this exception with Datomic Cloud production topology:

java.lang.RuntimeException: No such var: p/list-databases, compiling:(datomic/client/api/async.clj:78:3)

Running with com.datomic/client-cloud {:mvn/version "0.8.54"}.

typo, maybe? did you mean d/list-databases ?

The last call in my code before the trace goes into datomic is (d/client datomic-config).

ah

It appears to be some sort of race condition with Datomic's require. Has anyone experienced this?