Re: Making DBI (results) more strict

Max, you can distinguish a missing column from a null one quite easily in 
regular Perl.  If "exists $hash->{key}" is false then the column doesn't exist, 
where if that is true but "defined $hash->{key}" is false then it exists but is 
null. -- Darren Duncan

On 2/10/2014, 10:57 AM, Max Maischein wrote:
> Hi all,
>
> I recently discovered the greatness that is Hash::Util::lock_ref_keys , when
> used together with ->fetchall_arrayref() like this:
>
>      ...
>      my $rows= $sth->fetchall_arrayref( {} };
>      for( @$rows ) {
>          lock_ref_leys( $_ );
>      };
>      ...
>
> This prevents me from accessing hash keys that don't exist. Usually, this is
> inconvenient, but with SQL query results, I (too) often encounter different case
> for the column names, or other inconsistencies. Especially when columns are
> allowed to be NULL, it may take me a while to figure out that I'm looking at the
> wrong key.
>
> I'd like to enable this returning of locked hashes from within DBI, preferrably
> on a per-$dbh-level:
>
>      my $dbh= DBI->connect( $dsn, 'scott', 'tiger', { RaiseError => 1,
> StrictResults => 1 });
>
> Alternatively, I'm also open to suggestions on how to best implement this
> feature in a separate module, tentatively named DBI::strict. I've thought about
> doing some AUTOLOAD reflection onto the real $dbh, but I'm unsure about how to
> best approach wrapping arbitrary DBD handles/statement handles with my
> DBI::strict::st without interfering. Also, I'd appreciate hints on what
> subroutine(s) would be the most appropriate to enable locking the hashes, as I
> want to write as little new code for such a feature as necessary.
>
> Thanks for reading,
> -max
>