I'm using latest Datomic pro 1.0.7387. Latest Clojure on JDK 21. This is my first time building a system with datomic. I developed data input assuming java.time.Instant because I thought the datomic attribute type :db.type/instant mapped to that. Now I'm facing that :db.type/instant means java.util.Date. Can someone please shine some light on this and offer best practices for a non legacy solution like mine.
For instants, I convert at the application layer using something similar to what @jaret describes. For other java.time types (local dates, year-months, intervals, periods, durations, etc), I serialize to a string and convert at the application layer.
I recommend that you stick to java.util.Date under the hood on Datomic, and convert at the application layer. So transacting something like (java.util.Date/from (java.time.Instant/now)) and reading, something like (.toInstant ^java.util.Date (:my/date-attr (d/entity db eid))). I will be interested if others have other ideas or recommendations.
I think other customers may be encoding these types (instant, localDate, Localtime) as strings with serialization and then deserializing them in queries and rules.
And I have seen this around using java.time transparently: https://clojureverse.org/t/teach-java-time-instant-to-datomic-cloud-transact-and-pull/7698
We have a ticket for a feature request to support these primitive types, but it has not yet been prioritized. I will attach your thread to that ticket or if you have an e-mail we can notify you if we deliver a feature in this area.
There's also https://github.com/magnars/datomic-type-extensions, though having used it for a project for this date stuff, I think I've come agree with the above response and now avoid this sort of automatic wrapping and just accepting the use of java.util.Date.
I think because it's easier to remember that a :db.type/instant is just a java.util.Date vs having to remember all the abstraction leaks mentioned in that readme multiplied by the number of different type extensions I'm using and the number of attributes that use which ones.
would definitely be really nice to see these types natively supported. I subscribed to this thread for updates :)