Centralize all user-side rsrc calls to go through result_source()
[dbsrgits/DBIx-Class.git] / lib / DBIx / Class / Manual / Cookbook.pod
index 3270f03..ce68fc2 100644 (file)
@@ -125,9 +125,9 @@ almost like you would define a regular ResultSource.
   #
 
   # do not attempt to deploy() this view
-  __PACKAGE__->result_source_instance->is_virtual(1);
+  __PACKAGE__->result_source->is_virtual(1);
 
-  __PACKAGE__->result_source_instance->view_definition(q[
+  __PACKAGE__->result_source->view_definition(q[
     SELECT u.* FROM user u
     INNER JOIN user_friends f ON u.id = f.user_id
     WHERE f.friend_user_id = ?
@@ -1342,7 +1342,7 @@ row.
 
           # Abort the whole job
           if ($_ =~ /horrible_problem/) {
-            print "something horrible happend, aborting job!";
+            print "something horrible happened, aborting job!";
             die $_;                # rethrow error
           }
 
@@ -1737,12 +1737,11 @@ L<DBIx::Class::ResultSet/create> and L<DBIx::Class::Row/update> family of
 methods:
 
   $resultset->create({
-    numbers => [1, 2, 3]
+    numbers => [1, 2, 3],
   });
 
   $result->update({
-    numbers => [1, 2, 3]
-    day => '2008-11-24'
+    numbers => [1, 2, 3],
   });
 
 In conditions (e.g. C<\%cond> in the L<DBIx::Class::ResultSet/search> family of
@@ -1754,10 +1753,10 @@ passing them as bind values:
     numbers => { -value => [1, 2, 3] },
   });
 
-Alternatively:
+Or using the more generic (and more cumbersome) literal syntax:
 
   $resultset->search({
-    numbers => \[ '= ?', [numbers => [1, 2, 3]] ]
+    numbers => \[ '= ?', [ numbers => [1, 2, 3] ] ]
   });
 
 
@@ -1771,11 +1770,11 @@ C<< [column_name => value] >>.
 =head2 Formatting DateTime objects in queries
 
 To ensure C<WHERE> conditions containing L<DateTime> arguments are properly
-formatted to be understood by your RDBMS, you must use the C<DateTime>
+formatted to be understood by your RDBMS, you must use the L<DateTime>
 formatter returned by L<DBIx::Class::Storage::DBI/datetime_parser> to format
 any L<DateTime> objects you pass to L<search|DBIx::Class::ResultSet/search>
 conditions. Any L<Storage|DBIx::Class::Storage> object attached to your
-L<Schema|DBIx::Class::Schema> provides a correct C<DateTime> formatter, so
+L<Schema|DBIx::Class::Schema> provides a correct L<DateTime> formatter, so
 all you have to do is:
 
   my $dtf = $schema->storage->datetime_parser;
@@ -1794,12 +1793,11 @@ Without doing this the query will contain the simple stringification of the
 C<DateTime> object, which almost never matches the RDBMS expectations.
 
 This kludge is necessary only for conditions passed to
-L<DBIx::Class::ResultSet/search>, whereas
-L<create|DBIx::Class::ResultSet/create>,
-L<find|DBIx::Class::ResultSet/find>,
-L<DBIx::Class::Row/update> (but not L<DBIx::Class::ResultSet/update>) are all
+L<search|DBIx::Class::ResultSet/search> and L<DBIx::Class::ResultSet/find>,
+whereas L<create|DBIx::Class::ResultSet/create> and
+L<DBIx::Class::Row/update> (but not L<DBIx::Class::ResultSet/update>) are
 L<DBIx::Class::InflateColumn>-aware and will do the right thing when supplied
-an inflated C<DateTime> object.
+an inflated L<DateTime> object.
 
 =head2 Using Unicode