X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FDBIx%2FClass%2FManual%2FTroubleshooting.pod;h=820359d7c325ea08f6d1133cee7b98375d44aebe;hb=1415f198da91a23911972ad06b6dafaf6f4c0e8f;hp=5d468057c144e7f247598d1a257988c0fe0bf753;hpb=8d5a66b88fb9a4670fa09380621f4483f011d591;p=dbsrgits%2FDBIx-Class-Historic.git diff --git a/lib/DBIx/Class/Manual/Troubleshooting.pod b/lib/DBIx/Class/Manual/Troubleshooting.pod index 5d46805..820359d 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 version 1.50 and L 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 "" ... @@ -103,7 +102,7 @@ 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' ] } ); @@ -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 row objects in -memory, so can be unoticeable with certain data sets, but with huge +degradation exponential to the number of L row 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 test -suite in the file C +suite, in the C file. Further information on this issue can be found in L, @@ -150,7 +149,7 @@ L =head2 Excessive Memory Allocation with TEXT/BLOB/etc. Columns and Large LongReadLen -It has been observed, using L, that a creating a L +It has been observed, using L, that creating a L 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