ADBA feedback

[Mark Rotteveel]

On 30-4-2018 10:07, Lukas Eder wrote:
> I don't fully see the maintenance nightmare aspect here. In many years of
> working with JDBC, I don't recall having preferred (Stringly typed) name
> based access over index based access, neither in infrastructure code like
> some in-house JDBC libraries or jOOQ, nor in actual business logic.
> Especially infrastructure code works better with index based access,
> precisely because of the non-ambiguity.
> 
> Another example:
> 
> SELECT a, b + c, COUNT(*) OVER()
> FROM x
> 
> What is the column name of the second and third columns? In some databases,
> it might be "b+c" and "count". In others, it might be "B+C" and
> "COUNT(*)OVER()". Then there's the question about case sensitivity of
> column names. Will they be projected in upper case or lower case or mixed
> case? Can we rely on that? How to write database agnostic code that works
> the same on all databases?
 >
> You might be tempted to think that we could alias the columns with quoted
> identifiers, to be sure:
> 
> SELECT a, b + c AS "b", COUNT(*) OVER() AS "c"
> FROM x
> 
> But the caveat is:
> 
> 1) Some databases require quoted identifiers to be in [brackets], or in
> `backticks`
> 2) Some databases use quotes only to support special characters, not to
> make the identifiers case sensitive, so there still isn't any guarantee
> about the casing
> 
> Of course, a driver might choose to make the get(String) method case
> insensitive to work around the above, but as you can see, the only really
> reliable way to access columns is by index, and I do think they should be
> made first class citizens in the API (just like in JDBC) for the many
> reasons I've mentioned in this discussion.

Retrieval by column label in JDBC is case insensitive by specification, 
and I think that ADBA should maintain that. That is irrespective if the 
label was originally case sensitive or not.

Mark
-- 
Mark Rotteveel