Clojurians Log v2
honeysql
I'm running into some trouble with using postgres enums. I have an user-defined type for an enum called user_status. I'd want to use it from a query like this
{:select [:*]
:from [:users]
:where [:= :status [:user-status input-value]]}WHERE (status = USER STATUS("...")) . It works fine if I use :user_status in the dsl. My options are :check :strict :quoted-snake true.
Is there any way to achieve what I'm trying to do?
In my experience, transforming between kebab and other case is a nightmare. We use camelCase for columns, and I use them as-is in the code and the API. Otherwise I never knew whether at a particular point in code I was dealing with one or the other.
Why not simply use :user_status?
This behavior is documented here: https://cljdoc.org/d/com.github.seancorfield/honeysql/2.4.1026/doc/readme?q=function#functions
And, as it says, you should also be able to use :'user-status.
because i hoped to be able to use kebab-case everywhere. but i guess the ambiguity isn't worth it and i'll just make it a human-lint-rule to use snake_case for db-side stuff.
HoneySQL distinguishes between - and _ - it's part of the DSL.
I usually use kebab-case for schemas/tables/columns and snake-case for functions.
Is the discrepancy between how honey.sql formats quoted-snake and how the next.jdbc built-in as-kebab-maps formats the results known? honey.sql (imo correctly) just replaces - with while camel-snake-kebab that next.jdbc uses inserts a - between different character classes too. I ran into this problem because I had an emailmd5 column that I could query as :email-md5 but the result would come out as :email-md-5
CSK is an external library that I don't control but people were commonly using it for round-tripping kebab -> snake -> kebab with next.jdbc so I decided to just depend on it and offer shortcuts to use it.
I don't like using that conversion, personally, and prefer to just use snake case around the database -- you can always write your own builder if the CSK-based builder does not suit your needs.
yeah, i wrote a simple replace for this to work around the problem. it just felt weird that the "built-in" conversion worked on the querying side but not on the result side