Fork me on GitHub

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


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 to next.jdbc...


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


@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

seancorfield20:01:22 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 (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