@geraldodev Thanks. Was that for the options map?

Ah, yes, I can see how that would happen. I'll open an issue on that repo.

https://gitlab.com/nikperic/hugsql-next-jdbc/issues/2

@seancorfield can you strip a as clause "schema.table/fieldname" when .getTableName fails to handle oracle case ? I know I can use get-modified-column-names feeding :qualifier-fn and :label-fn but it is inefficient for this case because both functions would had to repeat the regular expression twice. It would be nice this at get-column-names level.

get-modfied-column-names also relies on getTableName so its not an option

The problem with my suggestion : To be really effective and the code compatible with other database than oracle it had to execute the regular expression on every case, because the getColumnName had to account for the name of the table to be embedded on it. making get-collumn-names slower.

a (or (.getTableName rsmeta i) (.getColumnLabel rsmeta i)) on https://github.com/seancorfield/next-jdbc/blob/30c668c86c8ef455b561d208be7b20b360da9b52/src/next/jdbc/result_set.clj#L48 would allow get-modifield-column-names to be used feeding :qualifier-fn and :label-fn allowing the oracle case to be handled and not hurting everyone else that luckily not use oracle 🙂

For oracle clojure.java.jdbc is a better option. It already lowers the case of identifiers by default. next.jdbc is optimized not to take the transformation hit. If your db is postgres fine, but if it is oracle you gotta inform that you want to lower the case query by query. That and the abcence of the main outcome of library that is namespacing keywords because of oracle jdbc driver makes me think clojure.java.jdbc is better alternative. And it already has reducible-query with {:raw? true} . Thank you Sean for both libraries 🙂

@geraldodev I'm afraid I don't understand what you're asking. clojure.java.jdbc's default is equivalent to the as-unqualified-lower-maps builder in next.jdbc which doesn't touch .getTableName at all. (or (.getTableName rsmeta i) (.getColumnLabel rsmeta i)) mixes table names and column names so that's just not correct.

If you want clojure.java.jdbc's :qualifier behavior in next.jdbc (i.e., a constant "table" qualifier for your column names, you can just provide a :label-fn #(str "qualifier/" %) and use as-unqualified-modified-maps.

(That makes me realize that the migration docs are incorrect -- they suggest :qualifier-fn (constantly "qualifier") which won't work for Oracle -- or in cases with other DBs where a table name is not available)

Note:

user=> (namespace (keyword "foo/bar"))
"foo"
user=> 

https://github.com/seancorfield/next-jdbc/issues/63 as a reminder for me to update the docs for 1.0.8

The suggestion was to use the as clause as a means to pass the qualifier. Unfortunately even this is not possible, with more than 30 characters we get the ORA-00972

Its interesting that the code above is clojure.java.jdbc. I didnt know that it could qualify with the as clause. Thats (keyword "a_table/cd_procedimento") in action

clojure.java.jdbc has :qualifier to provide a qualifier on keywords if that's any help.

Both c.j.j. and next.jdbc already use .getColumnLabel when naming columns.

.getColumnLabel returns the column name from the SQL -- which will be the alias if one was present. That's always been the case in both libraries.

Technically, you aren't "qualifying" in that code, you're just providing an alias -- a column label -- that contains a /. That happens to work for the same reason my code snippet above works: calling keyword on "foo/bar" produces a qualified keyword insofar as when you call namespace on it, you'll get "foo".

The example above is not practical due to size limits of the alias. If the namespace + column is short enough it's possible to use. The goal would be desambiguate collumns with equal names from different tables that are pulled through a join. That's good enough to me . (if not for the size limit)