Ask questions on the official Q&A site at https://ask.datomic.com!
kenny 2021-03-12T01:12:46.182100Z

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

ghadi 2021-03-12T01:45:48.182500Z

I don’t think so

ghadi 2021-03-12T01:48:34.184Z

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

zendevil 2021-03-12T16:51:48.185400Z

I’m running the following command:

./datomic client access my-stack-name
But I’m getting the following error:

zendevil 2021-03-12T16:51:54.185600Z

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

zendevil 2021-03-12T16:51:59.185900Z

How to fix this?

jaret 2021-03-12T17:21:33.187600Z

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

joshkh 2021-03-12T19:45:41.191200Z

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

Joe Lane 2021-03-12T19:57:23.193300Z

@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?

joshkh 2021-03-12T20:05:22.193400Z

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.

Joe Lane 2021-03-12T20:14:46.193700Z

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).


Happy to report a upgrade fixed these problems. Thanks!

joshkh 2021-03-12T20:46:20.194500Z

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.