This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (22)
- # architecture (6)
- # beginners (76)
- # cider (44)
- # clara (6)
- # clj-kondo (34)
- # cljdoc (4)
- # cljs-dev (8)
- # clojure (162)
- # clojure-brasil (4)
- # clojure-dev (32)
- # clojure-europe (3)
- # clojure-italy (16)
- # clojure-japan (4)
- # clojure-nl (3)
- # clojure-poland (1)
- # clojure-spec (25)
- # clojure-uk (45)
- # clojuredesign-podcast (5)
- # clojurescript (91)
- # clojutre (3)
- # core-async (19)
- # core-logic (8)
- # cursive (60)
- # data-science (3)
- # datomic (7)
- # defnpodcast (2)
- # duct (5)
- # emacs (7)
- # fulcro (1)
- # graalvm (9)
- # graphql (1)
- # jackdaw (12)
- # jobs (1)
- # jobs-discuss (1)
- # kaocha (3)
- # leiningen (3)
- # luminus (2)
- # off-topic (44)
- # onyx (17)
- # pathom (6)
- # planck (15)
- # re-frame (1)
- # reagent (13)
- # rum (2)
- # shadow-cljs (43)
- # spacemacs (3)
- # sql (43)
- # tools-deps (3)
- # vim (43)
- # xtdb (13)
I'm asking this here because I suspect the answer may depend on knowledge of internals of the compiler and/or the JVM. Background:
next.jdbc relies heavily on protocols and uses "native" Java types where possible for performance. That makes it really hard to pass around options since you can't "attach" them to arbitrary Java objects. There's a common request from users to be able to globally set a default for
:builder-fn -- which determines the naming conventions used when turning
ResultSet objects into Clojure hash maps. Currently, the code in
next.jdbc that handles that option does
(get opts :builder-fn as-maps) in several places. All those places have a
ResultSet object accessible so...
...the suggestion has been made for
next.jdbc to add a protocol, say
DefaultBuilder, that has an implementation for
Object that just returns
as-map. So that would become
(get opts :builder-fn (default-builder rs)) and the
Object implementation of
as-maps. Then users could
extend-protocol DefaultBuilder ResultSet (default-builder [_] my-custom-builder)...
First off, what's folks' reaction to that sort of thing? It feels hacky to me but it also seems feasible and, I hope, wouldn't have much of a performance impact (which is one of my main concerns here).
Second, given the constraints above, what would you suggest as a way to provide an overridable default for a function that is highly performant.
I get the impression that Clojure itself still relies on a bunch of dynamic Vars for some of this -- but I'm not sure whether that's in any performance-sensitive code?
The guidance for extending protocols is something like "only do it if you own the protocol or the type", which I think is to promote interoperability. In this case the user doesn't own the protocol (next.jdbc does), and doesn't own the type (Java jdbc) does. Resultset is also, if I recall, an interface, which brings other considerations because there is nothing like prefer-method for protocols (but I'd don't entirely recall the details here), so it is harder to specify a different behavior for a particularly implementation of resultset
ReadableColumn essentially break that guidance already: the assumption is the user will extend them to arbitrary types that they want converted in/out of SQL-specific types (e.g., having
Those have default implementations only for
next.jdbc (and mirror what
clojure.java.jdbc did too).
I don't understand why
(get opts :builder-fn as-maps) is not sufficient?
as-maps is not the default some people want -- and they don't want to override the default in every single call.
@alexmiller just thought I'd check with you first -- tools.reader ATM has quite an ugly hack in its implementation to support
tagged-literal in clojure <1.7.0, am considering bumping minimum requirement from clojure 1.4 to 1.7 and getting rid of that
Looks like perhaps some Google Groups changes went into effect recently. I received email about Google changing things there a month or so back, but didn't read the details of what would be changing. This may be unrelated, but there is a message waiting for moderation there that I currently do not have permission to approve or reject (or even look at), even though I got the usual email notification that a pending message is there.
they removed a bunch of features and simplified the admin setup but it was mostly around things we don't use
Perhaps everything is normal. The thing that looked different was a kind of pop-up warning box saying "Permission to manage messages denied". Perhaps it has always done that when the moderation message set is empty, and I just haven't noticed it before.
hmm, I haven't seen that. also, I don't know of anything that has changed
Yes, logged out and back in to Google account to verify. Still see that message, although given there are no pending messages, the real test will be when there is a message to moderate.
Eventually Google groups will chip away one capability of each Manager role person, until it takes 4 of them to do everything 🙂 (referring to this for me, and messages you send there showing up in the Groups page, but not in people's inboxes who subscribed)
almost everything about google groups is worse than it was 5 years ago
Looks like the non-SSL redirects to the SSL version now. Thank you!