Clojurians Log v2

It's all down to what JDBC itself returns from .getTableName() on the ResultSetMetaData object.

You can override it with :table-fn in a modified builder if you really need to, but understand that next.jdbc by default does whatever JDBC does (in terms of what or whether there is a table name associated with a column).

kk, that's helpful. We have a lot of views and I really just want to work with the view names, not the underlying table names. I'll do some playing around with :table-fn.

Thanks!

Are they materialized views or "plain" views? That might affect what JDBC returns...?

plain

Ah, so JDBC essentially maps the query to the underlying tables etc that the view is defined as I guess.

i.e., create or replace view foo as select * from foo_history

Since next.jdbc is using ResultSetMetaData, .getTableName() "Gets the designated column's table name." so it's operating at the column level in the result set (and metadata) so the view is "gone" at that point. Bear in mind that doing something like :table-fn (constantly "foo") will cause all columns in the result to be :foo/* even if they came from a different table/view or were computed (and would normally have no table name associated).

hmm, yes, good point. I'll have to ponder. I may have to remap the namespaced keys in clojure

I think that would be better/safer since it feels like you're dealing with application domain concerns rather than JDBC concerns. I guess I'd rephrase that as "why do you want the view name instead of the underlying table name?"

The table names are mostly junk, i.e., person_history, organisation_history, patient_history, clinician_history and so on

the view is easier to think about, person, organisation, patient, clinician.

But, I'l have a ponder.

Perhaps I'll just to have come-to-terms with my aesthetic desires

and go with history 🙂

Yeah, I'll go with history, might as well. I'll adapt 🙂

I think it's better, overall, to have the raw queries come back reflecting the underlying DB structure and then to have an explicit transform layer to turn that into app domain data. That's what we do at work, e.g., mapping all sorts of tables down to :wsbilling/* before handing it off to the domain logic.

I wonder if postgres will have different behavior here