This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-11-16
Channels
- # aleph (3)
- # announcements (14)
- # babashka (16)
- # beginners (85)
- # calva (6)
- # cider (9)
- # clojure (42)
- # clojure-australia (8)
- # clojure-europe (30)
- # clojure-nl (4)
- # clojure-uk (29)
- # clojuredesign-podcast (7)
- # clojurescript (25)
- # cursive (4)
- # data-science (1)
- # datomic (31)
- # emacs (1)
- # events (1)
- # fulcro (16)
- # instaparse (2)
- # java (37)
- # kaocha (3)
- # malli (3)
- # meander (19)
- # membrane (7)
- # off-topic (13)
- # pathom (4)
- # pedestal (10)
- # re-frame (17)
- # reveal (3)
- # rewrite-clj (1)
- # ring (9)
- # shadow-cljs (17)
- # spacemacs (2)
- # sql (34)
- # tools-deps (88)
- # vim (4)
@seancorfield In next.jdbc, you now have the as-*-snake-kebab
if the csk library is on the path. Would you consider also adding as-*-camel-case
? The rationale is that it's very common when interfacing with external consumers to send to them JSON (i.e., javascript frontends). Thus, having the ability to simply do, for example {:builder-fn rs/as-unqualified-camel-case-maps})
would help tremendously, rather than having to do something like this:
(defn camel-case
[rs opts]
(let [camelCase #(->camelCase %)]
(result-set/as-unqualified-modified-maps rs (assoc opts :qualifier-fn camelCase :label-fn camelCase))))
(Or, I was looking at the code on the v1 branch, and I could copy pasta the defmacro
for def-snake-kebab []
in the result_set.clj
)
I won't accept a PR for that: snake_case is much more common than camelCase (in both the DB tables/columns and in external JSON systems) and it's easy enough to write a builder to produce camelCase based on the existing adapters -- you could stick that function above in a common ns in your code and easily reuse it everywhere. Another argument against this is that it is fairly unlikely that an external system is going to just magically match your DB naming so an automatic conversion won't help you (and tying your DB structure directly to that external system's current naming convention is a Bad Idea(™) anyway).
I don't know which systems you work with, but in my experience, camelCase for JSON is a lot more common. I rarely see JSON of this form "foo_bar", more like "fooBar"
Fair enough. Either way, I only baked in snake/kebab because I kept seeing people reinvent it in buggy ways -- I still sort of regret it, since it's easy enough for folks to "do it right" with the CSK library. Yours is the first request I've seen for camelCase (ever, as far as I can remember, across all the years of c.j.j and next.jdbc).
And it's always you, isn't it? 🙂
Hi! I’ve been told to write about my concern here, so I’m reposting this: Does anyone have any experience with jdbc / mysql here? Namely I have an issue where after some time of inactivity, and then again trying to connect to the database .. it fails with a `Operation timed out (Read failed)` . I’ve been trying to find a way to configure it to reconnect on timeout, but haven’t yet found a way. Does anyone have any ideas?
How long is "some time of inactivity"? I seem to recall MySQL's JDBC driver auto-closes inactive connections after some time period (but I think it's hours).
I use HikariCP with PostgreSQL (I have used mysql and mariadb too), and it will keep the connection alive to the db, even when the db goes down, when it comes back up again, it will reestablish the connection. which is neat.
Korma is unmaintained and uses a very old clojure.java.jdbc version. I would suggest you reconsider that path. We really don't use ORM-style libraries in Clojure (but, if you must, look at Toucan which is at least still maintained).
yeah, agree there. I am sooo thankful of not having to mess around with hibernate or java jpa shenanigans since moving to clojure
Excuse my naiveness, I’m new to working in the back-end with Clojure, coming from CLJS. Thankfully my project is new enough to re-work that part rather easily, so I think I’ll just go with Hikari and report back! 🙂
saying that, I do also work in Kotlin and I can recommend JOOQ as a very nice abstraction layer (akin to honeysql/nextjdbc on Clojure)
If you want to see a stupid little example of using hikaricp and nextjdbc/honeysql (targeting a postgresql database, but it’s so simple, could be mysql/mariadb too), then here you go https://github.com/dharrigan/startrek/blob/master/src/startrek/db.clj
enjoy! I hope you find not having to worry about ORMs liberating! 🙂 of course, usual cavets apply, YMMV, don’t trust anyone on t’interwebs etc….
next.jdbc
has built-in support for connection pools with both HikariCP and c3p0 (we use the latter at work in production but most people use HikariCP).
We use HoneySQL very heavily in production at work, with a combination of clojure.java.jdbc
(in our legacy Clojure code) and next.jdbc
in our more recent code.
I maintain all three of those. This channel is good for general SQL Qs and also for c.j.j and next.jdbc
. There's a #honeysql channel if you want to dig into that library.