Fork me on GitHub

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 input-value is provided as a parameter. The problem is that quoted-snake doesn't seem to work (well) with this and generates 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?


Why not simply use :user_status?


This behavior is documented here: 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.

Jakub Holý (HolyJak)15:05:08

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.


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