Fork me on GitHub
#sql
<
2023-02-14
>
rgm21:02:25

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)

rgm21:02:29

Ah. Solid advice. Thanks.

seancorfield21:02:47

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.

rgm21:02:36

Oh interesting. Ok. That’s not too dissimilar to what I’m doing with multiple entries in a consumer’s deps.edn to avoid eg. having to drag in next.jdbc if you’re using the redis implementation and vice versa