This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-02-14
Channels
- # announcements (7)
- # babashka (13)
- # beginners (98)
- # biff (20)
- # calva (3)
- # clj-kondo (5)
- # clj-otel (6)
- # cljs-dev (96)
- # clojure (22)
- # clojure-austin (30)
- # clojure-conj (4)
- # clojure-europe (53)
- # clojure-nl (2)
- # clojure-norway (63)
- # clojure-uk (3)
- # clojurescript (18)
- # cursive (10)
- # data-science (11)
- # datalevin (2)
- # datomic (7)
- # deps-new (1)
- # fulcro (3)
- # graphql (1)
- # gratitude (4)
- # hyperfiddle (43)
- # kaocha (4)
- # malli (15)
- # pathom (6)
- # polylith (2)
- # reagent (3)
- # reitit (2)
- # releases (6)
- # remote-jobs (1)
- # rewrite-clj (45)
- # ring (4)
- # shadow-cljs (47)
- # sql (5)
- # xtdb (8)
I had a question about Postgres JSONB and making libraries.
I get a lot out of using this advice on using extend-protocol
around SettableParameter and ReadableColumn to auto-convert in and out of the database https://cljdoc.org/d/com.github.seancorfield/next.jdbc/1.3.847/doc/getting-started/tips-tricks#working-with-json-and-jsonb
But, I'm working on a library, and I'm concerned that finagling the protocols in my lib will have a fairly wide impact out to the rest of the JVM it's cohabiting with app code.
Do these scope to the JVM? If they do, is there a way to isolate the effect?
(My library-in-progress, for context: https://github.com/rgm/hyak2/blob/main/modules/fstore-postgres/src/hyak2/postgres_store.clj#L40-L41 ... here it's not all that big a deal to manually serialize/deserialize)
What next.jdbc
itself does is to isolate protocol extension on "3rd party types" to a specific namespace (and some specific functions) so that users can opt-in if they want but by default the library does not hijack types or protocols.