Merge branch 'current/for_cpan_index' into current/dq
[dbsrgits/DBIx-Class.git] / lib / DBIx / Class / Manual / Cookbook.pod
index 8648b7c..0cb560b 100644 (file)
@@ -428,6 +428,9 @@ literal SQL:
   # Equivalent SQL:
   # SELECT * FROM employee WHERE YEAR(date_of_birth) = ?
 
+To include the function as part of a larger search, use the '-and' keyword
+to collect the search conditions:
+
   $rs->search({ -and => [
     name => 'Bob',
     \[ 'YEAR(date_of_birth) = ?', 1979 ]
@@ -837,7 +840,7 @@ AKA multi-class object inflation from one table
 L<DBIx::Class> classes are proxy classes, therefore some different
 techniques need to be employed for more than basic subclassing.  In
 this example we have a single user table that carries a boolean bit
-for admin.  We would like like to give the admin users
+for admin.  We would like to give the admin users
 objects (L<DBIx::Class::Row>) the same methods as a regular user but
 also special admin only methods.  It doesn't make sense to create two
 separate proxy-class files for this.  We would be copying all the user
@@ -1105,7 +1108,7 @@ as follows:
 
 =head2 Filtering a relationship result set
 
-If you want to get a filtered result set, you can just add add to $attr as follows:
+If you want to get a filtered result set, you can just add to $attr as follows:
 
  __PACKAGE__->has_many('pages' => 'Page', 'book', { where => { scrap => 0 } } );
 
@@ -1160,14 +1163,14 @@ as each other and your connecting database user has the proper permissions to th
 To accomplish this one only needs to specify the DB schema name in the table
 declaration, like so...
 
-  package MyDatabase::Main::Artist;
+  package MyApp::Schema::Result::Artist;
   use base qw/DBIx::Class::Core/;
 
   __PACKAGE__->table('database1.artist'); # will use "database1.artist" in FROM clause
 
   __PACKAGE__->add_columns(qw/ artist_id name /);
   __PACKAGE__->set_primary_key('artist_id');
-  __PACKAGE__->has_many('cds' => 'MyDatabase::Main::Cd');
+  __PACKAGE__->has_many('cds' => 'MyApp::Schema::Result::Cd');
 
   1;
 
@@ -1180,10 +1183,10 @@ of your application to support a change lifecycle (e.g. DEV, TEST, PROD) and
 the DB schemas are named based on the environment (e.g. database1_dev).
 
 However, one can dynamically "map" to the proper DB schema by overriding the
-L<connection|DBIx::Class::Schama/connection> method in your Schema class and
+L<connection|DBIx::Class::Schema/connection> method in your Schema class and
 building a renaming facility, like so:
 
-  package MyDatabase::Schema;
+  package MyApp::Schema;
   use Moose;
 
   extends 'DBIx::Class::Schema';
@@ -1220,16 +1223,16 @@ building a renaming facility, like so:
 
   1;
 
-By overridding the L<connection|DBIx::Class::Schama/connection>
+By overriding the L<connection|DBIx::Class::Schema/connection>
 method and extracting a custom option from the provided \%attr hashref one can
 then simply iterate over all the Schema's ResultSources, renaming them as
 needed.
 
 To use this facility, simply add or modify the \%attr hashref that is passed to
-L<connection|DBIx::Class::Schama/connect>, as follows:
+L<connection|DBIx::Class::Schema/connect>, as follows:
 
   my $schema
-    = MyDatabase::Schema->connect(
+    = MyApp::Schema->connect(
       $dsn,
       $user,
       $pass,
@@ -1734,7 +1737,7 @@ methods:
     numbers => [1, 2, 3]
   });
 
-  $row->update(
+  $result->update(
     {
       numbers => [1, 2, 3]
     },
@@ -2187,7 +2190,7 @@ L<DBIx::Class|DBIx::Class> programs can have a significant startup delay
 as the ORM loads all the relevant classes. This section examines
 techniques for reducing the startup delay.
 
-These tips are are listed in order of decreasing effectiveness - so the
+These tips are listed in order of decreasing effectiveness - so the
 first tip, if applicable, should have the greatest effect on your
 application.