Clojurians Log v2

Hello, I'm using next-jdbc, and I'm trying to modify values based on their column (or Clojure key name) when I query data. I've written a build-fn which changes column labels to clojure keys (kebab case / namespaced). Now I'd like to modify the values of these columns based on their key (some columns need to be modified when read). Maybe there's a better way to achieve what I'm trying to do, but here's my current setup:

(defn my-kebab-case-builder [rs opts]
  (let [kebab #(string/replace % #"_" "-")
        opts (assoc opts :qualifier-fn kebab :label-fn kebab)]
    (result-set/as-modified-maps rs opts)))

(defn my-column-modifier [rs rsmeta i]
  ;; This doesn't return the modified column label
  (.getColumnLabel rsmeta i)
  (when-let [value (.getObject rs i)]
    ;; Do something based on column label
    value))

{:builder-fn (result-set/as-maps-adapter
              my-kebab-case-builder ;; e.g. Change "updated_at" to :person/updated_at
              my-column-modifier)}

@kevin.van.rooijen (.getColumnLabel rsmeta i) reads the column label directly from the underlying ResultSetMetaData Java object.

And my-column-modifier is called to read the column value, independently of how the column names are built.

Ok, so there's no way for me to get the new column name in that case?

The column name comes from the Java object -- the question doesn't really make sense.

The builder is how the Clojure data structure is built from the underlying Java objects.

Right, but I build the Clojure data structure based on the column name. Basically saying if a column is a specific keyword, I want to change it in a different way

But it sounds like I'm better off modifying the clojure keyword to a string, underscoring it, and passing it to my-column-modifier

Thanks for the info

@kevin.van.rooijen Reading columns from the ResultSet is completely independent from creating the Clojure keys in the map. There is no Clojure data structure or keyword "column name" at the point you read the column value from the ResultSet.

You could write your own adapter, i.e., reify both the RowBuilder and the ResultSetBuilder and then you'd have access to your builder and therefore to the new column names you are creating.

That sounds like an interesting option. I'll look into that, thanks

Start with as-maps-adapter and then you can get (:cols mrsb) inside the adapter and so you would have more control over how you read columns.

Line 240 (`next.jdbc.result-set`) and your column reader could use nth on (:cols mrsb) to get the Clojure keyword you've constructed for that column.

It's worth bearing in mind that the current adapter still calls read-column-by-index on the result of calling column-reader -- so you could simplify that in your version -- but that is done deliberately so the ReadableColumn protocol is in play (but if you're writing your own builder or adapter from scratch, you can make that decision).

I'm not really familiar with the internals, so I'll have to do some digging. But this'll give me a head start 🙂

I think I could add a new type of adapter that allowed more control to the caller. I'll have to give it some thought.

https://github.com/seancorfield/next-jdbc/issues/129

I am having trouble getting Postgres types to work with the IN clause:

(sql/query ds (honey/format {:select [:id :name :role]
                              :from   [:user]
                              :where [:in :role [(types/as-other "parent")]]}))

I assume the type meta data is getting lost when passing the map to honey/format, but unsure what I can do about it

Ah never mind, the following works:

(honey/call :cast "parent" :user_role)

@somedude314 Interesting. I'll create a ticket on HoneySQL to investigate whether metadata survives its transformations. It probably should if it can...

Actually, now I think about that, I think it is preserving the metadata (because it would get a different error if it wasn't).

That enum handling is a quirk of PostgreSQL so there may be contexts where it doesn't work -- it was added to support insert rather than select/in so it's entirely possible you have to use the more traditional cast approach in queries?