GSP
Quick Navigator

Search Site

Unix VPS
A - Starter
B - Basic
C - Preferred
D - Commercial
MPS - Dedicated
Previous VPSs
* Sign Up! *

Support
Contact Us
Online Help
Handbooks
Domain Status
Man Pages

FAQ
Virtual Servers
Pricing
Billing
Technical

Network
Facilities
Connectivity
Topology Map

Miscellaneous
Server Agreement
Year 2038
Credits
 

USA Flag

 

 

Man Pages
DBIx::Class::Manual::Troubleshooting(3) User Contributed Perl Documentation DBIx::Class::Manual::Troubleshooting(3)

DBIx::Class::Manual::Troubleshooting - Got a problem? Shoot it.

You're trying to make a query on a non-connected schema. Make sure you got the current resultset from $schema->resultset('Artist') on a schema object you got back from connect().

The "DBIC_TRACE" environment variable controls SQL tracing, so to see what is happening try

  export DBIC_TRACE=1

Alternatively use the "storage->debug" class method:-

  $schema->storage->debug(1);

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:-

  export DBIC_TRACE="1=/tmp/trace.out"

For some reason the table class in question didn't load fully, so the ResultSource object for it hasn't been created. Debug this class in isolation, then try loading the full schema again.

Older DBI and DBD::Pg versions do not handle "last_insert_id" correctly, causing code that uses auto-incrementing primary key columns to fail with a message such as:

  Can't get last insert id at /.../DBIx/Class/Row.pm line 95

In particular the RHEL 4 and FC3 Linux distributions both ship with combinations of DBI and DBD::Pg modules that do not work correctly.

DBI version 1.50 and 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. For example, for a schema " MySchema " you need to specify a fully qualified namespace: " package MySchema::MyTable; ".

This can happen if you have a relation whose name is a word reserved by your database, e.g. "user":

  package My::Schema::User;
  ...
  __PACKAGE__->table('users');
  __PACKAGE__->add_columns(qw/ id name /);
  __PACKAGE__->set_primary_key('id');
  ...
  1;

  package My::Schema::ACL;
  ...
  __PACKAGE__->table('acl');
  __PACKAGE__->add_columns(qw/ user_id /);
  __PACKAGE__->belongs_to( 'user' => 'My::Schema::User', 'user_id' );
  ...
  1;

  $schema->resultset('ACL')->search(
    {},
    {
      join => [qw/ user /],
      '+select' => [ 'user.name' ]
    }
  );

The SQL generated would resemble something like:

  SELECT me.user_id, user.name FROM acl me
  JOIN users user ON me.user_id = user.id

If, as is likely, your database treats "user" as a reserved word, you'd end up with the following errors:

1) syntax error at or near "." - due to "user.name" in the SELECT clause

2) syntax error at or near "user" - due to "user" in the JOIN clause

The solution is to enable quoting - see "Setting quoting for the generated SQL" in DBIx::Class::Manual::Cookbook for details.

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' ] } );

The above should be written as:

  $rs->search( {}, { order_by => { -desc => 'name' } } );

For more ways to express order clauses refer to "ORDER BY CLAUSES" in SQL::Abstract::Classic

There is a problem with slow performance of certain DBIx::Class operations using the system perl on some Fedora and Red Hat Enterprise Linux system (as well as their derivative distributions such as Centos, White Box and Scientific Linux).

Distributions affected include Fedora 5 through to Fedora 8 and RHEL5 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 free of this performance issue (this means all Fedora and RHEL5 systems 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

This issue is due to perl doing an exhaustive search of blessed objects under certain circumstances. The problem shows up as performance degradation exponential to the number of 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 susceptibility to the issue and performance effects of the bless/overload problem can be found in the DBIx::Class test suite, in the "t/99rh_perl_perf_bug.t" file.

Further information on this issue can be found in <https://bugzilla.redhat.com/show_bug.cgi?id=379791>, <https://bugzilla.redhat.com/show_bug.cgi?id=460308> and <http://rhn.redhat.com/errata/RHBA-2008-0876.html>

It has been observed, using DBD::ODBC, that creating a 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.

Check the list of additional DBIC resources.

This module is free software copyright by the DBIx::Class (DBIC) authors. You can redistribute it and/or modify it under the same terms as the DBIx::Class library.
2020-03-29 perl v5.32.1

Search for    or go to Top of page |  Section 3 |  Main Index

Powered by GSP Visit the GSP FreeBSD Man Page Interface.
Output converted with ManDoc.