Thanks for the explanation and the fix @seancorfield. I have one more question if that’s okay. I’m currently getting user-id
returned as snake case from execute-one!
with the following code:
(let [tab {:id (java.util.UUID/fromString "a768c90a-e1f2-4b66-bfd6-a9d8773dffd8"),
:name "foo",
:password ".Xp8",
:user-id (java.util.UUID/fromString "740cb441-ce5e-4f8f-b328-009dc44ebda6")}]
(nj/with-transaction [tx db]
(nj/execute-one! tx (-> (helpers/insert-into :tab)
(helpers/values [tab])
(helpers/returning :*)
(sql/format)))))
=> #:tab{:id #uuid"a768c90a-e1f2-4b66-bfd6-a9d8773dffd8",
:name "",
:password ".Xp8",
:created #object[java.time.OffsetDateTime 0x227987af "2021-04-02T01:30:20.962643Z"],
:updated #object[java.time.OffsetDateTime 0x46632f55 "2021-04-02T01:30:20.962643Z"],
:user_id #uuid"740cb441-ce5e-4f8f-b328-009dc44ebda6"}
Am I doing something wrong here? Thanks in advance.What is the column actually called in the DB @rextruong?
user_id
, hence the reason why I was asking about how HoneySQL handles conversion between the two cases.
You mentioned “it only affects 1) names in ResultSet’s that the library converts to Clojure” so that’s why I’m expecting user-id
instead
Since you are using the default result set builder, you get <table>/<column>
.
If you have Camel Snake Kebab on your classpath, that enables a couple of new result set builders that you can choose to use.
It doesn’t change the default behavior.
Ah that makes sense
next.jdbc
’s default is to leave names alone going in both directions (with the caveat that you get qualified names out).
I see. So I’d need to change the builder when I’m setting next.jdbc
up.
Will have a go at it now. Thanks a lot 🙂
You can specify :table-fn
and :column-fn
to affect how the “friendly” SQL functions deal with (Clojure data structure) input and you can specify :builder-fn
to affect how almost all functions deal with (`ResultSet` to Clojure data structure) output.
If you want a particular set of behaviors to be your “default” (for most calls), take a look at next.jdbc/with-options
but also be aware of the caveats around that near the end of https://cljdoc.org/d/seancorfield/next.jdbc/1.1.646/doc/getting-started#options--result-set-builders
HoneySQL operates completely “independently” of next.jdbc
insofar as all it does is turn Clojure data into SQL (plus parameters) so any translation of names there only corresponds to next.jdbc
’s “input” via the “friendly” SQL functions.
(I definitely need to clarify that in HoneySQL’s docs!)
So I was reading that link and I noticed that the examples are mostly just jdbc/get-datasource
. I assume with-options
also works with connection/->pool
?
Yes, because it “is-a” DataSource
.
Lovely. Thanks.
with-options
: “Given a connectable/transactable object and a set of (default) options that should be used on all operations on that object, return a new wrapper object that can be used in its place.” — a connectable is anything you can get a Connection
from.
(you just have to be careful that if you get a Connection
from it, that’s a bare Java object with no “options” attached)