Hey! I was expecting "named columns" (`select ... as myname from ...`) not to be namespaced. Was this an explicit decision? If so, is there any reasoning behind it that I can't see? I'm aware that I can customize the {:builder-fn ...}, so no big deal for me. But I'm curious.

select
	t1.title,
	t1.id,
	t2.rating
from
	t1 inner join t2 on t1.id = t2.t1_id
;
-- keys :t1/title :t1/id :t2/rating

select
	t1.title  as title,
	t1.id     as id,
	t2.rating as rating
from
	t1 inner join t2 on t1.id = t2.t1_id
;
-- keys still :t1/title :t1/id :t2/rating

https://github.com/seancorfield/next-jdbc/blob/master/doc/result-set-builders.md#rowbuilder-and-resultsetbuilder specifically the paragraph > The reason behind the default is ...

I follow and support the reasoning for referring to table names as qualified tables when the names of the columns of your query are inferred from the names of the columns. What surprises me is that explicitly naming a column (with AS) maintains the namespace "back" to the table.

Relevant from the link you provided, @dpsutton: > * If your SQL query joins tables in a way that produces duplicate column names, and you use unqualified column names, then those duplicated column names will conflict and you will get only one of them in your result -- use aliases in SQL (`as`) to make the column names distinct, > > * If your SQL query joins a table to itself under different aliases, the qualified column names will conflict because they are based on the underlying table name provided by the JDBC driver rather the alias you used in your query -- again, use aliases in SQL to make those column names distinct.

It depends on what the underlying JDBC driver provides. If it provides a non-empty table name for a given column, you'll get a qualified column name.

So in the case of simple aliases, for your particular JDBC driver, it maintains the table information from the original column.

next.jdbc has no "knowledge" about the SQL -- only what information the JDBC driver provides. That's why, for example, when using Microsoft's SQL Server JDBC driver, you only get qualified columns if you provide the driver-specific option at connection time to tell it to do that, and when using Oracle JDBC drivers, you don't get qualified columns at all. next.jdbc has no insight into the underlying machinery on the ResultSet -- it's a generic, portable library.

^ @teodorlu

(and neither of those caveats apply to your code, by the way)

> It depends on what the underlying JDBC driver provides. If it provides a non-empty table name for a given column, you'll get a qualified column name. > So in the case of simple aliases, for your particular JDBC driver, it maintains the table information from the original column. Ah, that makes a lot of sense. So the db driver "inferred" that the column was unchanged from the table it came from. Thanks!

JDBC can be very frustrating. It has a lot of quirks. And a lot of DB-specific behaviors.

I'm starting to realize that. I've used next.jdbc for a while now, and I must say that I'm starting to really appreciate the design. It seems to just "fit". I don't have any better word for it. That being said, I have a hard time explaining what's good about Clojure too.

Thanks. next.jdbc incorporates a lot of lessons learned from maintaining clojure.java.jdbc for eight years. I have a long block post in draft about that. One day I hope to finish and publish it.