Clojurians Log v2

I have been playing around a bit with HoneySQL and SQLingvo. I totally understand that nobody would like to use any other DB than Postgres anyways, but in the Enterprise, freedom of choice is limited. Are you aware of any efforts to 1. either provide a similar DSL but with an abstraction for vendor details beyond quoting (a.o. SQL dialects differ in their approach to: quoting, limiting, setting aliases, case sensitivity, ...) 2. or provide a similar DSL specifically tuned for Oracle?

@johannes.f.knauf HoneySQL is extensible so that people can written DB-specific extensions, so you could easily provide DB-specific libraries that used a common syntax, but implemented differently for each DB -- if you really wanted a DB-neutral DSL.

But the reality is that changing databases is very, very rare so DSL portability in code is not a real world consideration that anyone tends to care about.

So, I guess the answer to your question is, no, there are no efforts to do either 1. or 2. as far as I know.

I guess you refer to https://github.com/jkk/honeysql/blob/master/src/honeysql/format.cljc The extension API unfortunately is quite incomplete. format-clause methods, e.g. LIMIT, are hardcoded.

Well, forking might be an option. However, it feels a bit like the good old LISP curse: It's to simple to wrap your own library, that nobody ever builds and maintains reusable libraries.

Is there a way to configure next.jdbc to convert column names from kebab-case to snake_case and vice-versa when inserting and reading?

@jaime.sangcap Yes. You can pass in :column-fn and :table-fn to the next.jdbc.sql functions to convert Clojure names keywords to SQL names, and use a build adapter via :builder-fn to convert SQL names to Clojure names.

With the latter, the simplest solution is to use the as-modified-maps builder with :qualifier-fn and :label-fn.

This page https://cljdoc.org/d/seancorfield/next.jdbc/1.0.424/doc/getting-started/result-set-builders has an example of turning snake_case in SQL into kebab-case in Clojure.

@seancorfield Thanks for the pointers. It starts to make sense now ❤️

An excellent library to use with next.jdbc for that purpose is camel-snake-kebab -- that's what we use at work in a few places

How do you minimize repetition of passing the transformation functions (:table-fn, :column-fn, :builder-fn)? Do you wrap the next.jdbc.sql namespace like?

;; myapp.sql
  (defn as-kebab-maps [rs opts]
    (let [kebab #(clojure.string/replace % #"_" "-")]
      (result-set/as-modified-maps rs (assoc opts :qualifier-fn kebab :label-fn kebab))))
  
  (defn insert! [connectable table key-map]
    (jdbc/insert! connectable  table key-map {:builder-fn as-kebab-maps}))

{:table-fn #(clojure.string/replace % #"-" "_")
  :column-fn #(clojure.string/replace % #"-" "_")}

What I typically do is have a global (def default-jdbc-opts {...}) and just add that to every call.

I'm working on some way to set default options that doesn't cause a performance impact on people who don't use that but it's tricky since it relies heavily on Java SQL objects for performance (so there's no easy way to "wrap" things).

The Friendly SQL Functions page has this example BTW:

(defn snake-case [s] (str/replace s #"-" "_"))

(sql/insert! ds :my-table {:some "data"} {:table-fn snake-case})

I see. thanks for explaining