I suspect that it's due more to the database normalising the column name
before the DBD even sees it. Try this statement instead:
select 1 as "CamelCase"
On 28/02/17 20:26, Jonas B. Nielsen wrote:
Hi Nomad,
Thanks a lot.
This is what I need, but not what I am observing. I will do some more testing,
with the FetchHashKeyName set to NAME against SQLite. Then I will try to redo
the test against Oracle, I know DBD::Oracle defaults to uppercase, so I might
not be able to skip my translation dictionary anyway if NAME is not supported
and works as for DBD::SQLite
I reread the section on the docs
(https://metacpan.org/pod/DBI#FetchHashKeyName), and now it makes sense.
IMHO that NAME preserves casing is not completely clear due to the focus on
NAME_uc and NAME_lc and recommendation on their use.
Anyway thanks for the push in the right direction.
jonasbn
On 28 Feb 2017, at 21:13, no...@null.net wrote:
On Tue Feb 28, 2017 at 07:37:17PM +0100, Jonas B. Nielsen wrote:
- Would it be possible to have FetchHashKeyName preserve case? so if
a database was using camelCase this would be preserved.
A quick test seems to produce what you are looking for with the default
setting of "NAME":
#!/usr/bin/env perl
use strict;
use warnings;
use Data::Dumper;
use DBI;
my $db = DBI->connect('dbi:SQLite:db=:memory:');
my $sth = $db->prepare(q{SELECT 1 AS CamelCase});
$sth->execute;
print Dumper( $sth->fetchrow_hashref );
# Output is:
# $VAR1 = {
# 'CamelCase' => 1
# };
What kind of behaviour were you expecting?
Mark
--
Mark Lawrence
—
pauseid: JONASBN
email: jona...@cpan.org
twitter: @jonasbn
blog: https://lastmover.wordpress.com/
