The lack of java.time
support is getting more and more annoying as our code-base grows.
It turned out that even passing a YearMonth
value to a transaction function, which would convert it to java.util.Date
is not possible.
I've tried to extend the transit reader & writer handlers, but it was not sufficient, because somewhere along the way the YearMonth
instance has been converted into a com.cognitect.transit.impl.TaggedValueImpl
and stayed like that when it reached our transaction function.
The same transaction worked with d/with
though, because it doesn't seem to involve marshalling and unmarshalling.
I've even checked within datomic.client.impl.shared.io/marshal
, that the marshalled byte-array, when unmarshalled, is equal to the input (m
)
(defn- marshal
"Encodes val as Transit data in msgpack. Returns a map with keys:
:bytes - a Java byte array of the marshalled data
:length - the length in bytes of the marshalled data.
Note that for efficiency's sake the byte array may be longer than
the returned length."
[m]
(clojure.pprint/pprint m)
(let [stm (BytesOutputStream.)
w (transit/writer stm :msgpack {:handlers write-handlers})]
(transit/write w m)
(let [unmarshalled (unmarshal (java.io.ByteArrayInputStream. (.internalBuffer stm)))]
(clojure.pprint/pprint [unmarshalled (= m unmarshalled)]))
{:bytes (.internalBuffer stm)
:length (.length stm)}))
the result:
{:t 3857,
:next-t 3858,
:db-name "predict",
:database-id "6652bfa3-2e73-445f-8379-2448f824cbf3",
:tx-id #uuid "25c92f68-a931-44b7-b96d-c4be8fa147fb",
:tx-data
[[ginoco.datomic.component/loophole #time/year-month "2000-01"]],
:op :transact}
[{:t 3857,
:next-t 3858,
:db-name "predict",
:database-id "6652bfa3-2e73-445f-8379-2448f824cbf3",
:tx-id #uuid "25c92f68-a931-44b7-b96d-c4be8fa147fb",
:tx-data
[[ginoco.datomic.component/loophole #time/year-month "2000-01"]],
:op :transact}
true]