xtdb

Panel 2024-12-18T07:35:03.024159Z

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?

refset 2024-12-18T10:40:30.366219Z

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

refset 2024-12-18T10:41:42.498889Z

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)

Panel 2024-12-18T10:47:00.390719Z

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.

refset 2024-12-18T10:56:05.180199Z

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

refset 2024-12-18T10:57:18.991039Z

an upstream addition to next.jdbc may be the best solution, but I'm not entirely sure 🤔 hopefully Sean can chime in later

refset 2024-12-18T10:57:37.639919Z

it would definitely be better to have a consistent return type 🙂