Clojurians Log v2

Can anyone give any rough expected timings on Datomic Cloud operations (primarily datomic.client.api/q and datomic.client.api/transact). We're seeing about 60ms for q and 40ms for transact in the best case, which doesn't seem unreasonable given the overhead of an HTTP connection from the client to transactor etc, especially given we're going over a VPC boundary via a VPC endpoint pointing to the NLB (we didn't want to have to recreate all our existing infra, and Datomic Cloud templates require creating a new VPC, plus we're expecting to need to distribute the DBs across multiple clusters in future anyway). But it'd be useful to know if that was correct or if most people are seeing much lower timings. Especially if the VPC endpoint link is a probable cause for that.

whats the idiomatic way of modelling an ordered collection? an attribute with many cardinality does not enforce order, right? do you model each item in the collection as an entity with next/prev attributes? any helpers for this or do people just roll their own linked list?

there’s a thread about this https://forum.datomic.com/t/handling-ordered-lists/305/3

but I don’t think there’s a “one size fits all” solution, it depends on what you need

thanks, just wanted to double check I wasn’t reinventing the wheel here

I find that users usually want things either alphabetically or chronologically (or sorted on some column for table listings)… so explicit order needs are luckily rare in my experience

my use case is a task-list the user has prioritised herself. so order is kind of the point 🙂 storing an index/priority attribute seems to be the way to go

i've stood up a new Query Group to be used for Datomic Analytics, but after the stack updated i no longer see my catalogue in presto. we were previously using the default Analytics Endpoint and our catalogue was available for queries. 1. created a new Query Group called test-analytics 2. opened the compute stack CF template and entered the Query Group name test-analytics for the Analytics Endpoint field value 3. saved the stack and waited for the deployment to complete

presto> select * from system.metadata.catalogs;
 catalog_name | connector_id
--------------+--------------
 system       | system
(1 row)

@joshkh You need to pass the endpoint url for the QG not the name of the QG.

thanks, i was thrown off by the parameter description that says to provide the query group name. > Provide the name of a query group if you'd like analytic queries to go to a different endpoint. Defaults to system name. the endpoint url the EndpointAddress parameter from the query group CF output, right?

<http://entry>.&lt;query-group-name&gt;.&lt;region&gt;.<http://datomic.net:8182|datomic.net:8182>

Have you done the Cli sync dance? Those nodes wouldn’t have the catalogs in them unless you did.

i'll try again, maybe i did things out of step this time 🙂

we tried resyncing the metaschema again, no luck

I need some advice regarding storage: I've got some multi-dimensional vectors holding intergers or doubles (dtype-next tensors to be specific) and I wonder how to save those in Datomic. What I thought about is to save a tuple of the dimensions, say :some-ns/shape [3 5 4] and store the raw byte-buffer of a tensor along with it. I don't need to query the contents of it and would disable the history for it too. Is that a viable idea or should I rather serialize it and store the blob? If it's the latter: Are there examples of using an S3 bucket from inside a datomic ion?

Hmm. Can you open a support case so we can track this on official channels?

absolutely, thanks for the first attempt Joe!

The canonical answer here is "it depends" 🙂