$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>" ...
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:
-
- $rs->search( {}, { order_by => [ \'name DESC' ] } );
+Since L<DBIx::Class> >= 0.08100 and L<SQL::Abstract> >= 1.50 the above
+should be written as:
-Now you'll get SQL like this:
+ $rs->search( {}, { order_by => { -desc => 'name' } } );
- ... 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
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> 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<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>
+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 row objects are created, e.g. as the
The solution is to use the smallest practical value for LongReadLen.
+=head2 create_ddl_dir does not produce DDL for MySQL views
+
+L<SQL::Translator> does not create DDL for MySQL views if it doesn't know you
+are using mysql version 5.000001 or higher. To explicity set this version, add
+C<mysql_version> to the C<producer_args> in the C<%sqlt> options.
+
+ $schema->create_ddl_dir(['MySQL'], '1.0', './sql/', undef, { producer_args => { mysql_version => 5.000058 } })
+
=cut