More typo fixes

diff --git a/lib/DBIx/Class/Manual/Component.pod b/lib/DBIx/Class/Manual/Component.pod
index 46170f9..6865aac 100644 (file)
--- a/lib/DBIx/Class/Manual/Component.pod
+++ b/lib/DBIx/Class/Manual/Component.pod
@@ -27,7 +27,7 @@ by prepending the component name with a +.
 
   __PACKAGE__->load_components(qw/ +My::Component /);
 
-Once a component is loaded all of it's methods, or otherwise,
+Once a component is loaded all of its methods, or otherwise,
 that it provides will be available in your class.
 
 The order in which is you load the components may be very

diff --git a/lib/DBIx/Class/Manual/Features.pod b/lib/DBIx/Class/Manual/Features.pod
index 8f53a9c..a28bb35 100644 (file)
--- a/lib/DBIx/Class/Manual/Features.pod
+++ b/lib/DBIx/Class/Manual/Features.pod
@@ -274,7 +274,7 @@ I use populate L<here|http://blog.afoolishmanifesto.com/archives/1255> to export
 
 =head2 Multicreate
 
-Create an object and it's related objects all at once
+Create an object and its related objects all at once
 
  $schema->resultset('Author')->create({
     name => 'Stephen King',

diff --git a/lib/DBIx/Class/Manual/Glossary.pod b/lib/DBIx/Class/Manual/Glossary.pod
index 4feb8e1..9202ccc 100644 (file)
--- a/lib/DBIx/Class/Manual/Glossary.pod
+++ b/lib/DBIx/Class/Manual/Glossary.pod
@@ -127,7 +127,7 @@ See Join.
 
 =head2 prefetch
 
-Similiar to a join, except the related result objects are fetched and
+Similar to a join, except the related result objects are fetched and
 cached for future use, instead of used directly from the ResultSet.  This
 allows you to jump to different relationships within a Result without
 worrying about generating a ton of extra SELECT statements.

diff --git a/lib/DBIx/Class/Manual/Joining.pod b/lib/DBIx/Class/Manual/Joining.pod
index 1948be6..625a4d9 100644 (file)
--- a/lib/DBIx/Class/Manual/Joining.pod
+++ b/lib/DBIx/Class/Manual/Joining.pod
@@ -17,12 +17,12 @@ instead. Skip this part if you know what joins are..
 But I'll explain anyway. Assuming you have created your database in a
 more or less sensible way, you will end up with several tables that
 contain C<related> information. For example, you may have a table
-containing information about C<CD>s, containing the CD title and it's
+containing information about C<CD>s, containing the CD title and its
 year of publication, and another table containing all the C<Track>s
 for the CDs, one track per row.
 
 When you wish to extract information about a particular CD and all
-it's tracks, You can either fetch the CD row, then make another query
+its tracks, You can either fetch the CD row, then make another query
 to fetch the tracks, or you can use a join. Compare:
 
   SELECT ID, Title, Year FROM CD WHERE Title = 'Funky CD';

diff --git a/t/71mysql.t b/t/71mysql.t
index 9683451..58a5669 100644 (file)
--- a/t/71mysql.t
+++ b/t/71mysql.t
@@ -210,7 +210,7 @@ lives_ok { $cd->set_producers ([ $producer ]) } 'set_relationship doesnt die';
         INNER JOIN `artist` `artist` ON `artist`.`artistid` = `me`.`artist`
     )',
     [],
-    'overriden default join type works',
+    'overridden default join type works',
   );
 }