Fork me on GitHub
#sql
<
2021-06-05
>
Timofey Sitnikov13:06:23

Good morning, I am trying to figure out how to insert data into DB, with this code:

(jdbc/insert! db "auth_token" {:id  "35cf7140-b2d4-4b5d-9067-70fdae337a99"
                                 :account-id  "ffffffff-ffff-ffff-ffff-000000000100"
                                 :token  "7e58bcb3-198c-4884-998a-d3df08f1cb73"
                                 :email ""
                                 :expires-at  "2021-06-06T08:57:14.544792"}))
And I get the error:
Execution error (PSQLException) at org.postgresql.core.v3.QueryExecutorImpl/receiveErrorResponse (QueryExecutorImpl.java:2553).
ERROR: syntax error at or near "-"
  Position: 36
Any way to print out the query string to see where there is an issue?

seancorfield13:06:34

@timofey.sitnikov Because you have kebab-case key names.

seancorfield13:06:47

Those are not valid in SQL.

seancorfield13:06:55

Are you using next.jdbc?

seancorfield13:06:20

If so, you can leverage the snake-kebab-opts (if you’re using the latest version of next.jdbc).

Timofey Sitnikov14:06:14

@seancorfield, ahhh... thank you, that worked. I do use next.jdbc. . How do you use snake-kebab-opts ? I did find it https://github.com/seancorfield/next-jdbc/blob/8d02bd68f06a25300011532fed6dedab731f5990/src/next/jdbc.clj#L401 , but cannot figure out how to use it.

seancorfield14:06:05

It’s just options. You pass it into next.jdbc calls.

seancorfield14:06:40

It causes kebab-case keys to be converted to snake_case columns (and tables) and vice versa when result sets come back.

Timofey Sitnikov14:06:31

OK, like so?

(sql/insert! ds :address {:name "A. Person" :email ""} {:snake-kebab-opts true})

seancorfield14:06:59

No, it’s an options map.

seancorfield14:06:53

(sql/insert! ds :address {:name "A. Person" :email ""} jdbc/snake-kebab-opts)
Although in this case there’s no point: you don’t have any kebab-case keys.

3
seancorfield14:06:59

I guess the docs are not clear enough. Suggestions on how to improve them?

In addition, two pre-built option hash maps are available in next.jdbc, that leverage the camel-snake-kebab library:

snake-kebab-opts -- provides :column-fn, :table-fn, :label-fn, :qualifier-fn, and :builder-fn that will convert Clojure identifiers in :kebab-case to SQL entities in snake_case and will produce result sets with qualified :kebab-case names from SQL entities that use snake_case,
unqualified-snake-kebab-opts -- provides :column-fn, :table-fn, :label-fn, :qualifier-fn, and :builder-fn that will convert Clojure identifiers in :kebab-case to SQL entities in snake_case and will produce result sets with unqualified :kebab-case names from SQL entities that use snake_case.

seancorfield14:06:36

(this is in Getting Started, just after an example showing an options map with :builder-fn)

seancorfield14:06:13

Has anyone used next.jdbc/with-logging on the develop branch yet? Any feedback on it?

Timofey Sitnikov02:06:09

I tried it, but kept on scratching my head why it did not work and I could not find the function, now I know, need to use the development branch. 😂

seancorfield02:06:40

If you're using the CLI and deps.edn, you can rely on :git/url versions so you can test it direct from source.

3
thumbnail11:06:58

Yeah we've (team of 3) used in in development since the announcement to tap> queries and results. So far it has been a blessing! We tap queries before execution + a promise for the results, which are delivered in the second fn. (That way broken statements which result in exceptions still tap their value). Needed to play around with Datafy to remove those promises from the view, but over all 👍:skin-tone-2:

seancorfield15:06:54

@jeroen.dejong Thanks. Perhaps having try/`finally` in the JDBC logging code that still calls the second function would be a good solution there? Either with the exception in the result set slot or using an additional arity?

thumbnail16:06:56

That would certainly help! I think the exception in the result slot should be fine for my usecase at least

seancorfield17:06:00

https://github.com/seancorfield/next-jdbc/issues/166@jeroen.dejong I added your feedback. Would it help folks to test/provide feedback on this if I cut an actual “alpha” release to Clojars, with the understanding that with-logging is still experimental and will change in response to feedback before a non-alpha of 1.2.next? (I would prefer to not do that and have folks test it via :git/url but I understand that’s not ideal for everyone)

2
thumbnail20:06:42

My team uses lein git down just for this feature right now, happy to bump early and let you know how it works out :)

2
seancorfield15:06:54

@jeroen.dejong Thanks. Perhaps having try/`finally` in the JDBC logging code that still calls the second function would be a good solution there? Either with the exception in the result set slot or using an additional arity?

seancorfield17:06:00

https://github.com/seancorfield/next-jdbc/issues/166@jeroen.dejong I added your feedback. Would it help folks to test/provide feedback on this if I cut an actual “alpha” release to Clojars, with the understanding that with-logging is still experimental and will change in response to feedback before a non-alpha of 1.2.next? (I would prefer to not do that and have folks test it via :git/url but I understand that’s not ideal for everyone)

2