[Dbix-class] Problems while using the newest DBIx-Class-current

Matt S Trout dbix-class at trout.me.uk
Fri Jun 30 20:22:11 CEST 2006


Nilson Santos Figueiredo Junior wrote:
> Today I've decided to try out how the newest DBIx::Class would fare
> against our in production Catalyst application.
> 
> Unfortunately, the results weren't very good. The first resulted in a:
> 
> Deep recursion on subroutine "DBIx::Class::ResultSet::search" at C:/Nilson/stuff
> /cgi/MyTasks/script/../lib/MyTasks/Schema/ResultSet/Task.pm line 21.
> Deep recursion on subroutine "MyTasks::Schema::ResultSet::Task::search_rs" at C:
> /Nilson/stuff/cgi/MyTasks/script/../lib/DBIx/Class/ResultSet.pm line 141.
> 
> Now, I know that I don't need to define my own search_rs() anymore and
> if I drop its declaration, it works (at least the first request works,
> for now). So this issue was resolved and just made me aprehensive.
> 
> But then, another (maybe serious) issue came up. When trying to access
> a previously working Catalyst action, I started getting this:
> 
> Couldn't render template "undef error -
> DBIx::Class::ResultSet::count(): Error executing 'SELECT COUNT(
> DISTINCT( me.id ) ) FROM task_user me  JOIN task task ON ( task.id =
> me.task_id ) LEFT JOIN task_log logs ON ( logs.task_id = task.id )
> WHERE ( me.user_id = ? )': Unknown column 'me.id' in 'field list' at
> C:\Nilson\stuff\cgi\MyTasks\root\user\view.tt line 13
> "
> 
> This worries me a little bit since the upgrade to the newest DBIC
> might not be smooth as I thought it would be. The offending code in
> the template is a mere count() on the resultset. I'll try to provide
> as much code as possible so it might be easier to figure out the
> problem.
> 
> The resultset comes from the controller as:
> 
>   $c->stash->{tasks} = $user->tasks->search_hours_spent;
> 
> 
> The $user DBIC class is defined as:
> 
>     package MyTasks::Schema::User;
>     use warnings;
>     use strict;
>     use base qw/DBIx::Class/;
> 
>     __PACKAGE__->load_components(qw/PK::Auto Core/);
>     __PACKAGE__->table('user');
>     __PACKAGE__->add_columns(qw/id login passwd name type/);
>     __PACKAGE__->set_primary_key('id');
> 
>     # foreign keys
> 
>     # lançamentos realizados pelo usuário
>     __PACKAGE__->has_many('logs'       => 'MyTasks::Schema::TaskLog',
> 'user_id');
> 
>     # tarefas criadas pelo usuário
>     __PACKAGE__->has_many('created_tasks' => 'MyTasks::Schema::Task',
> 'creator_id');
> 
>     # tarefas do usuário
>     __PACKAGE__->has_many('task_users' => 'MyTasks::Schema::TaskUser',
> 'user_id');
>     __PACKAGE__->many_to_many('tasks' => 'task_users', 'task');
> 
> The search_hours_spent() is a method defined in
> MyTasks::Schema::Task's custom resultset class:
> MyTasks::Schema::ResultSet::Task. And it is defined as:
> 
>     sub search_hours_spent {
>         my $self = shift;
>         my $alias = $self->{attrs}{alias};
> 
>         $self->search(
>             undef,
>             {
>                 join     => [qw/logs/],
>                 select   => [(map {"${alias}.${_}"}
> $self->result_source->columns), {sum => 'logs.hours_spent'} ],
>                 as       => [$self->result_source->columns, qw/hours_spent/],
>                 group_by => ["${alias}.id"]
>             }
>         );
>     }
> 
> I don't know if there's something terribly wrong I'm doing, but since
> it worked on 0.06002 I suppose it should keep working. ;-)

I don't think {attrs}{alias} has been munged right as DBIC traversed the 
search_relateds in the many-many. Not sure exactly why though - can you have a 
dig around in that resultset and see what you've ended up with please?

-- 
      Matt S Trout       Offering custom development, consultancy and support
   Technical Director    contracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for more information

+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +



More information about the Dbix-class mailing list