Clojurians Log v2

Do the datoms in a transaction from a call to d/tx-range have any particular order?

I don’t think so

I was writing a transaction splitter for a decanting routine, and I remember explicitly sorting a tx by retractions first, then assertions

I’m running the following command:

./datomic client access my-stack-name

Execution error (ExceptionInfo) at datomic.tools.ops.aws/invoke! (aws.clj:83).
AWS Error: Unable to fetch region.

How to fix this?

Hi @ps do you have AWS credentials sourced? Datomic utilizes the sourced or specified https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html to operate. The CLI tools allow you to also pass a aws profile https://docs.datomic.com/cloud/operation/cli-tools.html#gen-opts

to test the performance of a query, i'd like to run it a few times while avoiding any caching effects. is it just a matter of using unique binding names in each execution? https://docs.datomic.com/cloud/query/query-executing.html#query-caching

@joshkh It sounds like you're attempting to test the performance of the query-as-edn->datalog-engine-format calculation. Are you suspecting that is a problem for you?

thanks for the reply. to be completely transparent i don't know much about the various layers of caching. the problem i'm trying to solve is that i have a handful of queries that perform badly, and better on subsequent executions. while debugging i don't know if my reordering of the constraints is actually helping or if caching is just doing its job.

I think it is highly unlikely that query-caching is what you're seeing. More likely, the data is not in the object-cache / valcache / memcached on the first run and have to be fetched from storage. Upon subsequent runs, the queries have the data in all of those caching layers and therefore is mostly CPU bound (what you want) instead of io bound (not what you want).

yup, that makes sense. thanks for clarifying. i had a feeling it wasn't as simple as caching query results based on how the query is compiled.