If I wanted to implement a retry loop for failing cas operations, what aspect of the thrown exception could I rely on to identify unambiguously a cas failure?

@danstone, I'd be interested in this as well

@danstone The string :db.error/cas-failed Compare failed indicates the failure is in the comparison

and the “Compare failed” part only gets thrown when the failure is in the comparison itself

hmm, it feels a bit like relying on undocumented details to me - it may be better to implement a generic transaction fn that throws a known type on not=

I was hoping there was some ex-info meta or something

I guess with these sort of remote CAS spin loops, a rather short time out is appropriate anyway, in which case I can just catch and if I get false positives it doesn't really matter too much

The data I would use this on would obviously have very low (read non-existent in normal usage) contention anyway

thanks for the info though @marshall 🙂

for a cardinality-many keyword attribute, can I write a query that says "the attribute should have all of these values"? (versus one that just says "this value should be among them")

can't you just add multiple where clauses?

@cap10morgan ^^

[e :attr v1] [e :attr v2] ...

@pesterhazy yeah, but I was hoping there was a way to do it where I could bind a set w/o knowing its size first or having to dynamically build where and in clauses based on it

I see

you could work around it by adding, say, 3 where clauses and then adding a filter you don't over-count results

just a thought 🙂

in theory datalog is just data and that's great, in practice it is data that is much simpler to write as literals in a text editor than it is to manipulate programmatically 🙂

often you can just filter results in clojure, rather than trying to express everything in datalog

which is much more straightforward

but obviously this has performance implications, depending on the result set

perhaps someone might be able to help me out here, I just migrated a datomic DB from one dynamoDB table to another, restoring it to a differently named URL in the process, e.g. datomic:ddb://<zone>/foo/name1 -> datomic:ddb://<zone>/bar/name2 . I seem to be able to connect to the DB but I am getting invalid-entity on attempting to transact against it. and I can query the value given in the exception just fine. could the renaming via URL be the cause of this behavior?

the :db-id in the connection still reflects name1

is it on the same transactor, @djjolicoeur ?

new transactor

@jaret @marshall 🙂

@robert-stuttaford is the fact that it is not on the same transactor an issue? we are in the process of restoring to the original name on the new table

Our local Datomic expert @rwtnorton wrote a great command-line operations tool for people to do simple queries and data fixes against Datomic using an SQL 92 syntax. Think psql for Datomic. We just open-sourced that at https://github.com/untangled-web/sql-datomic

it would appear that the renaming via new URL was the culprit. restore to the original DB name on the new table seems to have fixed the issue.