Passing Attributes to DBI Methods
Handles carry with them their set of current attribute values that methods often use to control how they behave. Many methods are defined to also accept an optional reference to a hash of attribute values.
This is primarily an escape mechanism for driver developers and their users, and so does not always work in the way you might think. For example, you might expect this code:
$dbh->{RaiseError} = 1;
...
$dbh->do( $sql_statement, undef, { RaiseError => 0 } ); # WRONGto turn off RaiseError for the
do() method call. But it doesn’t! Attribute
parameters are ignored by the DBI on
all database handle and statement handle method
calls. You don’t even get a warning that the attribute has been
ignored.
If
they’re ignored, then
what’s the point in having them? Well, the DBI itself ignores
them, but the DBD driver that processed the method
call may not. Or then again, it may! Attribute hash parameters to
methods are hints to the driver and typically
only usefully hold driver-specific attributes.[54]
That doesn’t apply to the
DBI->connect() method call
because it’s not a driver method, it’s a DBI method. Its
attribute hash parameter,
\%attr
, is used to set
the attributes of the newly created database handle. We gave some
examples using RaiseError in Chapter 4, and we give more in the following section.
[54] It’s possible that a future version of the DBI may look
for certain non-driver-specific attributes, such as
RaiseError.