Clojurians Log v2

Hello, does next.jdbc has something built-in to leave out from the result set map entries with nil values?

@jjaws https://cljdoc.org/d/seancorfield/next.jdbc/1.1.613/api/next.jdbc.optional

It's mentioned in the Result Set Builders section of the documentation https://cljdoc.org/d/seancorfield/next.jdbc/1.1.613/doc/getting-started/result-set-builders#nextjdbcoptional

aha my bad, thank you

you though of all the good stuff, great lib

Thanks. I expected to use the optional stuff a lot more than I have. But we have a large legacy code base and still have to preserve nil in that, even where we're switching from clojure.java.jdbc to next.jdbc...

Have those nils cause any trouble? would you say you are better off without them?

FWIW, https://github.com/brianc/node-postgres/issues/1336#issuecomment-309914315 😉

@jjaws I'm not sure how that relates to the optional null issue -- can you elaborate?

If you do a join in next.jdbc, the columns are qualified with the table name (by default) so you get (the equivalent of) {:users/uid 1, :sessions/uid nil, ...} and if you decide to use the "optional" builders then :sessions/uid would be omitted -- because it is null, not because it overlaps.

(if you use unqualified map builders, you get collisions and last-one-wins -- which is documented and that's why the (default) qualified builders are recommended)

@seancorfield yeah, was just shock that the node client doesn't have this feature

was unrelated to the null issue

clojure.java.jdbc had logic for making columns unique, but the problem with that was you couldn't tell which of uid, uid_1, uid_2, etc came from which tables. next.jdbc just punts on the issue completely: if you use table-qualification, it's "solved" unless you're joining a table to itself (also mentioned in the docs -- you have to explicitly alias the joined column to disambiguate).

yep, using as all over the place with the nodejs client was tedious, next.jdbc does the right ergonomic thing.

my original unrelated question was more about the use of nil in maps in your legacy code base, has it cause any frustrating issues?

"legacy code base" is complicated in our case. Our legacy apps are not all Clojure, so the hash maps from clojure.java.jdbc (and now next.jdbc) get handed back to non-Clojure code where is-the-key-present? and is-the-key-value-null? are substantially different questions so preserving nil-valued keys is important, unfortunately.

If I were starting over with pure Clojure code that was not going to be reused by non-Clojure code, I would likely be more aggressive about using the optional builders and having a codebase where "absence" was the decider rather than "nullable".

got it, was just curious about nil in maps in practice

https://corfield.org/blog/2018/12/06/null-nilable-optionality/ talks about it.