PersistentVector can also become arraylist

And this is indeed because of fressian serialization. It doesn’t have to be this way but these are the handlers they chose (maybe for performance)

I've also been bitten by this

I'm always processing arguments like this when writing transaction functions:

...
  (:import (java.util HashSet List)
...

(defn to-clojure-types [m]
  (walk/prewalk
    (fn [e]
      (cond (instance? HashSet e)
            (into #{} e)

            (and (instance? List e) (not (vector? e)))
            (vec e)

            :else e))
    m))

It’s surprising but I’ve rarely found that it matters (which is why it’s annoying when it bites!)

e.g. queries return HashSet/ArrayList at the top.

clojure interop with j.u.Collections is really good

in theory.. yes, but at least coll? returns false for java.util.HashSet

map etc work fine, so perhaps it’s just an oversight? not sure.

I guess the big thing was that it works differently on the transactor, compared to in memory, which was really surprising.. hard to write tests that cover this without quite some gymnastics..

Running a full fledged container with datomic would catch this, right? I should look into clj-test-containers: https://github.com/javahippie/clj-test-containers

A month has passed already... I "solved" this problem in the following way using https://github.com/clojure/data.fressian:

(ns com.github.ivarref.add-fressian
  (:require [clojure.data.fressian :as fress]
            [datomic.api :as d]))

(defn transact [org-transact]
  (fn [conn tx-data]
    (org-transact conn (fress/read (fress/write tx-data)))))

(defn with-fressian [f]
  (with-redefs [d/transact (transact d/transact)]
    (f)))

(test/use-fixtures :each add-fressian/with-fressian)

Thanks for pointing this out @U3ZUC5M0R! You saved me a lot of frustrating debugging time 🙏

PS: You can test remote transactor funtcions' behavior if you want using https://github.com/sikt-no/datomic-testcontainers/. There is also https://github.com/ivarref/gen-fn for writing datomic functions that automatically de-mangles fressian types into regular Clojure ones. I've documented the differences https://github.com/ivarref/gen-fn/blob/main/test/com/github/ivarref/remote_vs_local_test.clj#L79-L93, as part of gen-fn. Disclaimer (?): I wrote both these libraries.

I also just got bitten by this, due to using vector? in a db-fn (though sequential? would also cause issues). I was wondering if there is a reason they don't use the same serialization with in-memory transactors to patch this deviation of behavior?

I wonder how many have been bitten by this, and how many hours have been wasted... They could e.g. add a function transact2 which has identical types on both in-mem and remote transactor

would there be a need for a new name in this case, given it would be bringing parity to the two versions?

Oh, it's been answered before https://stackoverflow.com/questions/47693495/datomic-on-a-peer-does-connection-db-read-your-writes-after-connection-trans The answer is: yes, the guarantee is there

https://yyhh.org/blog/2021/11/t-wand-beat-lucene-in-less-than-600-lines-of-code/ This isn't Datomic, but it is an example of adding full text search to a different Datalog based DB.

oh nice, thanks for the tip

this actually sounds really promising 😳