I tried using clojure 1.10.0-beta7 and datomic 0.9.5703 but during the uberjar runtime, I got this exception: java.lang.IllegalStateException: Attempting to call unbound fn: #'datomic.common/requiring-resolve

I upgraded my uberjar from clojure 1.10.0-beta5 to clojure 1.10.0-beta7. looks like requiring-resolve was added to clojure.core in clojure 1.10.0-beta6

hi, is there any Datomic Console alternative?

would a feature request like this have interest from the cognitect side? we've had some queries return way more than expected because typos caused clauses to not unify. Would there be interest for some type of "strict" mode that would throw an error if an identifier other than _ or a logical variable that starts with "_" (like ?_customer) did not unify?

this current one was from ?schedule and ?schedlue not unifying

Is there a way to shrink the size of blobs written to storage? Our transactors are trying to write 27MB at a time to MySQL (5.6.34), which throws the MySQL exception The size of BLOB/TEXT data inserted in one transaction is greater than 10% of redo log size. Increase the redo log size using innodb_log_file_size. We can't change that parameter without incurring downtime -- I'm hoping there's a knob we can turn in datomic to split that 27mb blob up. As it is, that exception means our transactors cycle every 2-3 minutes because they can't finish indexing

related to above, can I query in datalog for all transactions that have a size greater than N?

@jchen you should not have segments that large. are you making very large transactions?

Datomic should not be used to store BLOBs or other large unstructured data

Also, you should consider this a critical issue @jchen if your system can’t complete an indexing job it will eventually reach a point where it is no longer available for writes

You need to get the system past this indexing job and resolve the underlying issue that is causing the large segments

the most common causes for large segments are: storing large blob values, making very large transactions (many datoms), or storing large strings that are frequently updated in a way that the leading bits are unchanged (i.e. we’ve had users storing serialized HTML or CSS in a string and updating it frequently with updates that only alter content somewhere deep into the string)

Thanks for the reply @marshall. The index job eventually succeeded: we noticed that the :kv-cluster/create-val bufsize peaked at around 27.8mb while throwing exceptions, then slowly dropped to 26.8mb and succeeded. This is the second time in two days we've had this issue -- the first time it also seemed to resolve itself without any intervention.

@jchen i would definitely look for any instances of the types of usage patterns i mentioned above Do you have a paid Datomic On-Prem license or is this with Starter?

We've got a paid license. I think in general we don't have many large transactions (the largest tx we found in the last 2 days was 300kb), and we have some 50kb blob attributes

@jchen i would suggest you file a support ticket Are the blob attributes frequently updated?