DBIx-Class
view release on metacpan or search on metacpan
lib/DBIx/Class/Storage/DBI.pm view on Meta::CPAN
);
}
sub _do_connection_actions {
my ($self, $method_prefix, $call, @args) = @_;
try {
if (not ref($call)) {
my $method = $method_prefix . $call;
$self->$method(@args);
}
elsif (ref($call) eq 'CODE') {
$self->$call(@args);
}
elsif (ref($call) eq 'ARRAY') {
if (ref($call->[0]) ne 'ARRAY') {
$self->_do_connection_actions($method_prefix, $_) for @$call;
}
else {
$self->_do_connection_actions($method_prefix, @$_) for @$call;
}
}
else {
$self->throw_exception (sprintf ("Don't know how to process conection actions of type '%s'", ref($call)) );
}
}
catch {
if ( $method_prefix =~ /^connect/ ) {
# this is an on_connect cycle - we can't just throw while leaving
# a handle in an undefined state in our storage object
# kill it with fire and rethrow
$self->_dbh(undef);
$self->throw_exception( $_[0] );
}
else {
carp "Disconnect action failed: $_[0]";
}
};
return $self;
}
sub connect_call_do_sql {
my $self = shift;
$self->_do_query(@_);
}
sub disconnect_call_do_sql {
my $self = shift;
$self->_do_query(@_);
}
=head2 connect_call_datetime_setup
A no-op stub method, provided so that one can always safely supply the
L<connection option|/DBIx::Class specific connection attributes>
on_connect_call => 'datetime_setup'
This way one does not need to know in advance whether the underlying
storage requires any sort of hand-holding when dealing with calendar
data.
=cut
sub connect_call_datetime_setup { 1 }
sub _do_query {
my ($self, $action) = @_;
if (ref $action eq 'CODE') {
$action = $action->($self);
$self->_do_query($_) foreach @$action;
}
else {
# Most debuggers expect ($sql, @bind), so we need to exclude
# the attribute hash which is the second argument to $dbh->do
# furthermore the bind values are usually to be presented
# as named arrayref pairs, so wrap those here too
my @do_args = (ref $action eq 'ARRAY') ? (@$action) : ($action);
my $sql = shift @do_args;
my $attrs = shift @do_args;
my @bind = map { [ undef, $_ ] } @do_args;
$self->dbh_do(sub {
$_[0]->_query_start($sql, \@bind);
$_[1]->do($sql, $attrs, @do_args);
$_[0]->_query_end($sql, \@bind);
});
}
return $self;
}
=head2 connect_call_rebase_sqlmaker
This on-connect call takes as a single argument the name of a class to "rebase"
the SQLMaker inheritance hierarchy upon. For this to work properly the target
class B<MUST> inherit from L<DBIx::Class::SQLMaker::ClassicExtensions> and
L<SQL::Abstract::Classic> as shown below.
This infrastructure is provided to aid recent activity around experimental new
aproaches to SQL generation within DBIx::Class. You can (and are encouraged to)
mix and match old and new within the same codebase as follows:
package DBIx::Class::Awesomer::SQLMaker;
# you MUST inherit in this order to get the composition right
# you are free to override-without-next::method any part you need
use base qw(
DBIx::Class::SQLMaker::ClassicExtensions
<< OPTIONAL::AWESOME::Class::Implementing::ExtraRainbowSauce >>
SQL::Abstract::Classic
);
<< your new code goes here >>
... and then ...
my $experimental_schema = $original_schema->connect(
sub {
( run in 1.695 second using v1.01-cache-2.11-cpan-39bf76dae61 )