Re: Question on FetchHashKeyName

"Jonas B. Nielsen" <[email protected]> Tue, 28 Feb 2017 21:26:49 +0100

Newsgroups	gmane.comp.lang.perl.modules.dbi.general
Message-ID	<[email protected]>

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/

signature.asc (application/pgp-signature, 842 B)