I really like this library, and would like to use it more ... a couple of thoughts

[technosophist]

We have an existing application that I would like to move to honeyeql. There are two barriers to that. First, our tables and columns do not follow the expected naming conventions (if I could start from scratch I would!). In fact, our tables aren't even consistently named. We use [table]/[field] for our keywords, but honeysql includes the schema. I would need a way to customize how table names are turned into qualified keywords.

Second, we use PosgreSQL enums which we convert into keywords on the way out and have to CAST on the way in. honeyeql will return strings, but I could not find a way to CAST. I experimented with adding an extensible way to handle custom types. master...thoughtfull-systems:honeyeql:coerce-other-type

The alternative is to rewrite a lot of code and the cost/benefit doesn't quite work out.

Would you be interested in trying to solve either of these problems? I don't necessarily have any preconceived solutions, and I think I'd be willing to help. Otherwise I may work on them in my fork and you're welcome to pull in anything that looks useful.

[tamizhvendan]

Hi @technosophist,

For the second, enums to keyword, I am already contemplating solving it by the following two approaches (both are not supported/implemented yet)

1. Have a library-level configuration to treat enums as keywords

:enum-deserialization-mode 
; possible values
:plain-string (default)
:plain-keyword (like `:green`) 
:keyword-with-type (like `:color/green` where `color` the type of the enum in DB) 
:keyword-with-type-and-schema (like `:desktop.color/green` where `desktop` is the schema)

2. In the configuration, selectively specify the serialize and deserialize overrides at the attribute level. Something like below

{:tool/brush-color {:serialize string :deserialize keyword}}

[tamizhvendan]

@technosophist For the first one, Can you provide a sample SQL schema with current and expected attribute names to understand it better?

[technosophist]

We're using the as-maps builder-fn in next.jdbc. So if we have a table:

inventory.unit(id uuid)

where inventory is the schema and unit is the table, our data comes back as

[{:unit/id #uuid ".."}{:unit/id #uuid "..."}]

honeyeql returns

[{:inventory.unit/id #uuid ".."}{:inventory.unit/id #uuid "..."}]

[technosophist]

Sorry, I think I must be remembering wrong, because I don't see any indication in the documentation about the schema in the column keys.

I'll have to take a look at my spike again and refresh my memory. It may not have been adding the schema, but converting to kebab case. We just use the columns as the come out of the database, underscores and all.

The enums was one thing.

I think the JSON parsing was another. Again I seem to recall that JSON was automatically camelCased or something? But we just use strings and kebab case in our PostgreSQL JSON data. I also see that there's a configuration for how JSON fields are parsed, so maybe I should try that.

I seem to recall the way the relationships were inferred was a little odd, like the names seemed duplicative, redundant, and I think it was because we don't follow the naming conventions of honeyeql.

I'll take a look at my code again and give a more complete and precise report. Sorry for the confusion.