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 )