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/
signature.asc
Description: Message signed with OpenPGP using GPGMail
