Fork me on GitHub
#sql
<
2021-01-27
>
JohnJ04:01:38

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

JohnJ04:01:16

aha my bad, thank you

JohnJ04:01:18

you though of all the good stuff, great lib

seancorfield04:01:34

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...

JohnJ16:01:16

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

seancorfield18:01:42

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

seancorfield18:01:04

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.

seancorfield18:01:44

(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)

JohnJ19:01:14

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

JohnJ19:01:58

was unrelated to the null issue

seancorfield20:01:22

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).

JohnJ21:01:05

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

JohnJ21:01:09

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

seancorfield21:01:05

"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.

seancorfield21:01:12

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".

JohnJ21:01:08

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