X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FDBIx%2FClass%2FManual%2FTroubleshooting.pod;h=f76934ec2c2f72b28861c58d9ae07bc9494db55d;hb=cd784aab86565e35c3aa9ba13fa2ea3e95616ec3;hp=5d468057c144e7f247598d1a257988c0fe0bf753;hpb=8d5a66b88fb9a4670fa09380621f4483f011d591;p=dbsrgits%2FDBIx-Class.git

diff --git a/lib/DBIx/Class/Manual/Troubleshooting.pod b/lib/DBIx/Class/Manual/Troubleshooting.pod
index 5d46805..f76934e 100644
--- a/lib/DBIx/Class/Manual/Troubleshooting.pod
+++ b/lib/DBIx/Class/Manual/Troubleshooting.pod
@@ -23,7 +23,7 @@ To send the output somewhere else set debugfh:-
 
   $schema->storage->debugfh(IO::File->new('/tmp/trace.out', 'w');
 
-Alternatively you can do this with the environment variable too:-
+Alternatively you can do this with the environment variable, too:-
 
   export DBIC_TRACE="1=/tmp/trace.out"
 
@@ -51,9 +51,8 @@ L<DBI> version 1.50 and L<DBD::Pg> 1.43 are known to work.
 
 There's likely a syntax error in the table class referred to elsewhere
 in this error message.  In particular make sure that the package
-declaration is correct, so for a schema C< MySchema > you need to
-specify a fully qualified namespace: C< package MySchema::MyTable; >
-for example.
+declaration is correct. For example, for a schema C< MySchema >
+you need to specify a fully qualified namespace: C< package MySchema::MyTable; >.
 
 =head2 syntax error at or near "<something>" ...
 
@@ -97,13 +96,13 @@ up with the following errors:
 2) syntax error at or near "user" - due to "user" in the JOIN clause
 
 The solution is to enable quoting - see
-L<DBIx::Class::Manual::Cookbook/Setting_quoting_for_the_generated_SQL> for
+L<DBIx::Class::Manual::Cookbook/Setting quoting for the generated SQL> for
 details.
 
 =head2 column "foo DESC" does not exist ...
 
 This can happen if you are still using the obsolete order hack, and also
-happen to turn on sql-quoting.
+happen to turn on SQL-quoting.
 
   $rs->search( {}, { order_by => [ 'name DESC' ] } );
 
@@ -113,7 +112,7 @@ should be written as:
   $rs->search( {}, { order_by => { -desc => 'name' } } );
 
 For more ways to express order clauses refer to
-L<SQL::Abstract/ORDER_BY_CLAUSES>
+L<SQL::Abstract/ORDER BY CLAUSES>
 
 =head2 Perl Performance Issues on Red Hat Systems
 
@@ -133,15 +132,15 @@ with full current updates will not be subject to this problem):-
   Fedora 8     - perl-5.8.8-41.fc8
   RHEL5        - perl-5.8.8-15.el5_2.1
 
-The issue is due to perl doing an exhaustive search of blessed objects
+This issue is due to perl doing an exhaustive search of blessed objects
 under certain circumstances.  The problem shows up as performance
-degredation exponential to the number of L<DBIx::Class> row objects in
-memory, so can be unoticeable with certain data sets, but with huge
+degradation exponential to the number of L<DBIx::Class> result objects in
+memory, so can be unnoticeable with certain data sets, but with huge
 performance impacts on other datasets.
 
-A pair of tests for susceptability to the issue, and performance effects
+A pair of tests for susceptibility to the issue and performance effects
 of the bless/overload problem can be found in the L<DBIx::Class> test
-suite in the file C<t/99rh_perl_perf_bug.t>
+suite, in the C<t/99rh_perl_perf_bug.t> file.
 
 Further information on this issue can be found in
 L<https://bugzilla.redhat.com/show_bug.cgi?id=379791>,
@@ -150,11 +149,11 @@ L<http://rhn.redhat.com/errata/RHBA-2008-0876.html>
 
 =head2 Excessive Memory Allocation with TEXT/BLOB/etc. Columns and Large LongReadLen
 
-It has been observed, using L<DBD::ODBC>, that a creating a L<DBIx::Class::Row> 
-object which includes a column of data type TEXT/BLOB/etc. will allocate 
-LongReadLen bytes.  This allocation does not leak, but if LongReadLen 
-is large in size, and many such row objects are created, e.g. as the 
-output of a ResultSet query, the memory footprint of the Perl interpreter 
+It has been observed, using L<DBD::ODBC>, that creating a L<DBIx::Class::Row>
+object which includes a column of data type TEXT/BLOB/etc. will allocate
+LongReadLen bytes.  This allocation does not leak, but if LongReadLen
+is large in size, and many such result objects are created, e.g. as the
+output of a ResultSet query, the memory footprint of the Perl interpreter
 can grow very large.
 
 The solution is to use the smallest practical value for LongReadLen.