Re: Question on FetchHashKeyName
Peter Haworth <[email protected]>
| Newsgroups | gmane.comp.lang.perl.modules.dbi.general |
|---|---|
| Message-ID | <[email protected]> |
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, [email protected] 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: [email protected] > twitter: @jonasbn > blog: https://lastmover.wordpress.com/ > > > > >