With the current progress made in next.jdbc and xtdb beta 4, could we round trip such clojure data:
{:_id 42
:top-level-time (Instant/now)
:user/name "Alice"
:user/preferences {:theme "dark"
:notifications #{:email :push}
:favorite-numbers [1 2 3.14159]}
:user/metadata {:created-at (Instant/now)
:last-login (ZonedDateTime/now)
:tags #{"active" "premium"}}}
The recursive keyword namespace works, set are returned as vector and dates as string except the top level one get returned as #inst.
Should I have a schema that decode the values coming out of the DB or is this level of round tripping feasible by default?Hey @avocabio you are observing the output of JSON-ified results, to get the proper Clojure/edn types back you need to add a parameter to the connection fallback_output_format=transit, e.g. see https://github.com/xtdb/xtdb/blob/7ff7b960bcab4ee7a25c1f6c2b8186d26f0d5767/src/test/clojure/xtdb/pgwire_test.clj#L1886-L1898
apologies this hasn't made it's way to the docs yet
sets and nested insts should then work fine - but bear in mind that sets aren't really catered for in SQL just yet (we need more std lib for working with them)
Cool it works:
{:xt/id 42, :given-name nil, :top-level-time #inst "2024-12-18T10:42:03.223511000-00:00", :top-level-zdt #inst "2024-12-18T10:42:03.223658000-00:00", :user/metadata {:last-login #time/zoned-date-time "2024-12-18T21:42:03.223686+11:00[Australia/Sydney]", :created-at #time/zoned-date-time "2024-12-18T10:42:03.223682Z[UTC]", :tags #{"premium" "active"}}, :user/name "Alice", :user/preferences {:theme "dark", :user/favorite-numbers [1 2 3.14159], :notifications #{:email :push}}}
Is it expected that the top level key value dates are parsed different than the nested one ?
In this example with the transit option I get #time/zoned-date-time back on nested field and a #inst on the top level one.expected is perhaps a bit strong 😄 but I think I get why it's happening - probably needs a read-as-zdt in next.jdbc https://cljdoc.org/d/com.github.seancorfield/next.jdbc/1.3.981/api/next.jdbc.date-time - otherwise the default is instant
an upstream addition to next.jdbc may be the best solution, but I'm not entirely sure 🤔 hopefully Sean can chime in later
it would definitely be better to have a consistent return type 🙂