lib/DBIx/Class/Manual/Troubleshooting.pod

   1 =head1 NAME
   2
   3 DBIx::Class::Manual::Troubleshooting - Got a problem? Shoot it.
   4
   5 =head2  "Can't locate storage blabla"
   6
   7 You're trying to make a query on a non-connected schema. Make sure you got
   8 the current resultset from $schema->resultset('Artist') on a schema object
   9 you got back from connect().
  10
  11 =head2 Tracing SQL
  12
  13 The C<DBIC_TRACE> environment variable controls
  14 SQL tracing, so to see what is happening try
  15
  16   export DBIC_TRACE=1
  17
  18 Alternatively use the C<< storage->debug >> class method:-
  19
  20   $schema->storage->debug(1);
  21
  22 To send the output somewhere else set debugfh:-
  23
  24   $schema->storage->debugfh(IO::File->new('/tmp/trace.out', 'w');
  25
  26 Alternatively you can do this with the environment variable too:-
  27
  28   export DBIC_TRACE="1=/tmp/trace.out"
  29
  30 =head2 Can't locate method result_source_instance
  31
  32 For some reason the table class in question didn't load fully, so the
  33 ResultSource object for it hasn't been created. Debug this class in
  34 isolation, then try loading the full schema again.
  35
  36 =head2 Can't get last insert ID under Postgres with serial primary keys
  37
  38 Older L<DBI> and L<DBD::Pg> versions do not handle C<last_insert_id>
  39 correctly, causing code that uses auto-incrementing primary key
  40 columns to fail with a message such as:
  41
  42   Can't get last insert id at /.../DBIx/Class/Row.pm line 95
  43
  44 In particular the RHEL 4 and FC3 Linux distributions both ship with
  45 combinations of L<DBI> and L<DBD::Pg> modules that do not work
  46 correctly.
  47
  48 L<DBI> version 1.50 and L<DBD::Pg> 1.43 are known to work.
  49
  50 =head2 Can't locate object method "source_name" via package
  51
  52 There's likely a syntax error in the table class referred to elsewhere
  53 in this error message.  In particular make sure that the package
  54 declaration is correct, so for a schema C< MySchema > you need to
  55 specify a fully qualified namespace: C< package MySchema::MyTable; >
  56 for example.
  57
  58 =head2 syntax error at or near "<something>" ...
  59
  60 This can happen if you have a relation whose name is a word reserved by your
  61 database, e.g. "user":
  62
  63   package My::Schema::User;
  64   ...
  65   __PACKAGE__->table('users');
  66   __PACKAGE__->add_columns(qw/ id name /);
  67   __PACKAGE__->set_primary_key('id');
  68   ...
  69   1;
  70
  71   package My::Schema::ACL;
  72   ...
  73   __PACKAGE__->table('acl');
  74   __PACKAGE__->add_columns(qw/ user_id /);
  75   __PACKAGE__->belongs_to( 'user' => 'My::Schema::User', 'user_id' );
  76   ...
  77   1;
  78
  79   $schema->resultset('ACL')->search(
  80     {},
  81     {
  82       join => [qw/ user /],
  83       '+select' => [ 'user.name' ]
  84     }
  85   );
  86
  87 The SQL generated would resemble something like:
  88
  89   SELECT me.user_id, user.name FROM acl me
  90   JOIN users user ON me.user_id = user.id
  91
  92 If, as is likely, your database treats "user" as a reserved word, you'd end
  93 up with the following errors:
  94
  95 1) syntax error at or near "." - due to "user.name" in the SELECT clause
  96
  97 2) syntax error at or near "user" - due to "user" in the JOIN clause
  98
  99 The solution is to enable quoting - see
 100 L<DBIx::Class::Manual::Cookbook/Setting_quoting_for_the_generated_SQL> for
 101 details.
 102
 103 =head2 column "foo DESC" does not exist ...
 104
 105 This can happen if you are still using the obsolete order hack, and also
 106 happen to turn on sql-quoting.
 107
 108   $rs->search( {}, { order_by => [ 'name DESC' ] } );
 109
 110 Since L<DBIx::Class> >= 0.08100 and L<SQL::Abstract> >= 1.50 the above
 111 should be written as:
 112
 113   $rs->search( {}, { order_by => { -desc => 'name' } } );
 114
 115 For more ways to express order clauses refer to
 116 L<SQL::Abstract/ORDER_BY_CLAUSES>
 117
 118 =head2 Perl Performance Issues on Red Hat Systems
 119
 120 There is a problem with slow performance of certain DBIx::Class
 121 operations using the system perl on some Fedora and Red Hat Enterprise
 122 Linux system (as well as their derivative distributions such as Centos,
 123 White Box and Scientific Linux).
 124
 125 Distributions affected include Fedora 5 through to Fedora 8 and RHEL5
 126 upto and including RHEL5 Update 2. Fedora 9 (which uses perl 5.10) has
 127 never been affected - this is purely a perl 5.8.8 issue.
 128
 129 As of September 2008 the following packages are known to be fixed and so
 130 free of this performance issue (this means all Fedora and RHEL5 systems
 131 with full current updates will not be subject to this problem):-
 132
 133   Fedora 8     - perl-5.8.8-41.fc8
 134   RHEL5        - perl-5.8.8-15.el5_2.1
 135
 136 The issue is due to perl doing an exhaustive search of blessed objects
 137 under certain circumstances.  The problem shows up as performance
 138 degredation exponential to the number of L<DBIx::Class> row objects in
 139 memory, so can be unoticeable with certain data sets, but with huge
 140 performance impacts on other datasets.
 141
 142 A pair of tests for susceptability to the issue, and performance effects
 143 of the bless/overload problem can be found in the L<DBIx::Class> test
 144 suite in the file C<t/99rh_perl_perf_bug.t>
 145
 146 Further information on this issue can be found in
 147 L<https://bugzilla.redhat.com/show_bug.cgi?id=379791>,
 148 L<https://bugzilla.redhat.com/show_bug.cgi?id=460308> and
 149 L<http://rhn.redhat.com/errata/RHBA-2008-0876.html>
 150
 151 =head2 Excessive Memory Allocation with TEXT/BLOB/etc. Columns and Large LongReadLen
 152
 153 It has been observed, using L<DBD::ODBC>, that a creating a L<DBIx::Class::Row>
 154 object which includes a column of data type TEXT/BLOB/etc. will allocate
 155 LongReadLen bytes.  This allocation does not leak, but if LongReadLen
 156 is large in size, and many such row objects are created, e.g. as the
 157 output of a ResultSet query, the memory footprint of the Perl interpreter
 158 can grow very large.
 159
 160 The solution is to use the smallest practical value for LongReadLen.
 161
 162 =cut
 163