From: Matt S Trout <mst@shadowcat.co.uk>
Date: Thu, 18 May 2006 13:19:02 +0000 (+0000)
Subject: Merge 'trunk' into 'DBIx-Class-current'
X-Git-Tag: v0.07002~75^2~189
X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=14574c41f268be47c9b54270b9e10421d9ea656e;p=dbsrgits%2FDBIx-Class.git

Merge 'trunk' into 'DBIx-Class-current'

r8675@cain (orig r1649):  castaway | 2006-05-17 09:28:27 +0000
Documentation updates

r8676@cain (orig r1650):  zarquon | 2006-05-17 09:49:18 +0000
optimised last_insert_id example for searching
r8691@cain (orig r1659):  castaway | 2006-05-18 09:48:30 +0000
Add pod for params of inflate/deflate coderefs
---

14574c41f268be47c9b54270b9e10421d9ea656e
diff --cc lib/DBIx/Class/Manual/Cookbook.pod
index 081a4d0,20efc71..f83d7ee
--- a/lib/DBIx/Class/Manual/Cookbook.pod
+++ b/lib/DBIx/Class/Manual/Cookbook.pod
@@@ -786,64 -786,17 +786,77 @@@ It is possible to get a Schema object f
  This can be useful when you don't want to pass around a Schema object to every
  method.
  
 +=head2 Profiling
 +
 +When you enable L<DBIx::Class::Storage::DBI>'s debugging it prints the SQL
 +executed as well as notifications of query completion and transaction
 +begin/commit.  If you'd like to profile the SQL you can subclass the
 +L<DBIx::Class::Storage::Statistics> class and write your own profiling
 +mechanism:
 +
 +  package My::Profiler;
 +  use strict;
 +
 +  use base 'DBIx::Class::Storage::Statistics';
 +
 +  use Time::HiRes qw(time);
 +
 +  my $start;
 +
 +  sub query_start {
 +    my $self = shift();
 +    my $sql = shift();
 +    my $params = @_;
 +
 +    print "Executing $sql: ".join(', ', @params)."\n";
 +    $start = time();
 +  }
 +
 +  sub query_end {
 +    my $self = shift();
 +    my $sql = shift();
 +    my @params = @_;
 +
 +    printf("Execution took %0.4f seconds.\n", time() - $start);
 +    $start = undef;
 +  }
 +
 +  1;
 +
 +You can then install that class as the debugging object:
 +
 +  __PACKAGE__->storage()->debugobj(new My::Profiler());
 +  __PACKAGE__->storage()->debug(1);
 +
 +A more complicated example might involve storing each execution of SQL in an
 +array:
 +
 +  sub query_end {
 +    my $self = shift();
 +    my $sql = shift();
 +    my @params = @_;
 +
 +    my $elapsed = time() - $start;
 +    push(@{ $calls{$sql} }, {
 +        params => \@params,
 +        elapsed => $elapsed
 +    });
 +  }
 +
 +You could then create average, high and low execution times for an SQL
 +statement and dig down to see if certain parameters cause aberrant behavior.
 +
+ =head2 Getting the value of the primary key for the last database insert
+ 
+ AKA getting last_insert_id
+ 
+ If you are using PK::Auto, this is straightforward:
+ 
+   my $foo = $rs->create(\%blah);
+   # do more stuff
+   my $id = $foo->id; # foo->my_primary_key_field will also work.
+ 
+ If you are not using autoincrementing primary keys, this will probably
+ not work, but then you already know the value of the last primary key anyway.
+ 
  =cut
diff --cc lib/DBIx/Class/Relationship.pm
index b5d6932,6048fd0..f9f85c2
--- a/lib/DBIx/Class/Relationship.pm
+++ b/lib/DBIx/Class/Relationship.pm
@@@ -141,18 -142,14 +144,19 @@@ foreign class store the calling class'
  columns. You should pass the name of the column in the foreign class as the
  $cond argument, or specify a complete join condition.
  
 -As well as the accessor method, a method named C<< add_to_<relname> >>
 -will also be added to your Row items, this allows you to insert new
 -related items, using the same mechanism as in L<DBIx::Class::Relationship::Base/"create_related">.
 +Three methods are created when you create a has_many relationship.  The first
 +method is the expected accessor method.  The second is almost exactly the same
 +as the accessor method but "_rs" is added to the end of the method name.  This
 +method works just like the normal accessor, except that it returns a resultset
 +no matter what, even in list context. The third method, named
 +C<< add_to_<relname> >>, will also be added to your Row items, this allows
 +you to insert new related items, using the same mechanism as in
 +L<DBIx::Class::Relationship::Base/"create_related">.
  
  If you delete an object in a class with a C<has_many> relationship, all
- related objects will be deleted as well. However, any database-level
- cascade or restrict will take precedence.
+ the related objects will be deleted as well. However, any database-level
+ cascade or restrict will take precedence. To turn this behavior off, pass
+ C<< cascade_delete => 0 >> in the $attr hashref.
  
  =head2 might_have