To send the output somewhere else set debugfh:-
- $schema->storage->debugfh(IO::File->new('/tmp/trace.out', 'w');
+ $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"
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>" ...
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.
-Note that quoting may lead to problems with C<order_by> clauses, see
-L<... column "foo DESC" does not exist ...> for info on avoiding those.
-
=head2 column "foo DESC" does not exist ...
-This can happen if you've turned on quoting and then done something like
-this:
+This can happen if you are still using the obsolete order hack, and also
+happen to turn on SQL-quoting.
$rs->search( {}, { order_by => [ 'name DESC' ] } );
-This results in SQL like this:
-
- ... ORDER BY "name DESC"
-
-The solution is to pass your order_by items as scalar references to avoid
-quoting:
+Since L<DBIx::Class> >= 0.08100 and L<SQL::Abstract> >= 1.50 the above
+should be written as:
- $rs->search( {}, { order_by => [ \'name DESC' ] } );
+ $rs->search( {}, { order_by => { -desc => 'name' } } );
-Now you'll get SQL like this:
-
- ... ORDER BY name DESC
+For more ways to express order clauses refer to
+L<SQL::Abstract/ORDER BY CLAUSES>
=head2 Perl Performance Issues on Red Hat Systems
White Box and Scientific Linux).
Distributions affected include Fedora 5 through to Fedora 8 and RHEL5
-upto and including RHEL5 Update 2. Fedora 9 (which uses perl 5.10) has
+up to and including RHEL5 Update 2. Fedora 9 (which uses perl 5.10) has
never been affected - this is purely a perl 5.8.8 issue.
As of September 2008 the following packages are known to be fixed and so
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>,
=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.
-=cut
+=head1 FURTHER QUESTIONS?
+
+Check the list of L<additional DBIC resources|DBIx::Class/GETTING HELP/SUPPORT>.
+
+=head1 COPYRIGHT AND LICENSE
+This module is free software L<copyright|DBIx::Class/COPYRIGHT AND LICENSE>
+by the L<DBIx::Class (DBIC) authors|DBIx::Class/AUTHORS>. You can
+redistribute it and/or modify it under the same terms as the
+L<DBIx::Class library|DBIx::Class/COPYRIGHT AND LICENSE>.