Bug #3305 for Class-DBI: has_many cause compilation error

Thu Aug 21 07:46:01 2003 Guest - Ticket created

Subject:

has_many cause compilation error

Under the following conditions has_many give a compilation error (object method _essential not found in Class:DBI::Querry line 114) to produce the error, create a file p1.pm package p1; use base 'Class::DBI'; p1->has_many('m' => 'main'); 1; then run the following line perl -wle ' use p1; use base q/Class::DBI/; main->columns(All => "m"); '

Fri Aug 22 13:37:40 2003 tony [...] kasei.com - Correspondence added

Date:	Fri, 22 Aug 2003 18:37:34 +0100
From:	Tony Bowden <tony [...] kasei.com>
To:	Guest via RT <bug-Class-DBI [...] rt.cpan.org>
Subject:	Re: [cpan #3305] has_many cause compilation error
RT-Send-Cc:

On Thu, Aug 21, 2003 at 07:46:01AM -0400, Guest via RT wrote: Show quoted text

> Under the following conditions has_many give a compilation error (object method _essential not found in Class:DBI::Querry line 114) > to produce the error, create a file p1.pm > package p1; > use base 'Class::DBI'; > p1->has_many('m' => 'main'); > 1; > then run the following line > perl -wle ' use p1; use base q/Class::DBI/; main->columns(All => "m"); '

I'm not sure why this is a bug. You're trying to link p1 with main, but main isn't a subclass of Class::DBI, so of course it's not going to work ... It could conceivably give a better error message, but I'm assuming there's a reason why you're reporting this? Tony

Fri Sep 12 06:02:43 2003 TMTM [...] cpan.org - Correspondence added

I can't see any simple way to fix this. But, as the example you provided is so contrived, I'm not really that concerned about it. I assume that this is just a cut down version for a bug report, and you actually encountered this is real code? If there are likely circumstances that trigger this I'll probably pay it more attention ...

Wed Nov 26 08:49:01 2003 Guest - Correspondence added

[tony@kasei.com - Fri Aug 22 13:37:40 2003]: Show quoted text

> On Thu, Aug 21, 2003 at 07:46:01AM -0400, Guest via RT wrote:

> > Under the following conditions has_many give a compilation error

> (object method _essential not found in Class:DBI::Querry line 114)

> > to produce the error, create a file p1.pm > > package p1; > > use base 'Class::DBI'; > > p1->has_many('m' => 'main'); > > 1; > > then run the following line > > perl -wle ' use p1; use base q/Class::DBI/; main->columns(All =>

> "m"); ' > > I'm not sure why this is a bug. > > You're trying to link p1 with main, but main isn't a subclass of > Class::DBI, so of course it's not going to work ... > > It could conceivably give a better error message, but I'm assuming > there's a reason why you're reporting this? > > Tony >

main is a subclass of Class::DBI. the problem is the order of the declaration. main uses p1, before declaring it base class. this causes the compilation to fail. It does not need to be considered a bug. But in that case it should be in the documentation. It needs specific care if there are circular has_many references.

Sat Jun 18 05:41:00 2005 TMTM [...] cpan.org - Correspondence added

Show quoted text

> main is a subclass of Class::DBI.

This is too contrived for my little brain. If you give an example that uses classes other than 'main' I'll look at it again. Thanks, Tony

Sat Jun 18 06:16:43 2005 Guest - Correspondence added

[TMTM - Sat Jun 18 05:41:00 2005]: Show quoted text

> > main is a subclass of Class::DBI.

> > This is too contrived for my little brain. If you give an example that > uses classes other than 'main' I'll look at it again.

## In file p1.pm package p1; use base 'Class::DBI'; p1->has_many('m' => 'p2'); 1; ## In file p2.pm package p2; use p1; # or any other class that use p1 use base 'Class::DBI'; 1; ## execute perl -wle ' use p2; ' Can't locate object method "meta_info" via package "p2" at /usr/local/lib/perl5/site_perl/5.8.6/Class/DBI/Relationship/HasMany.pm line 28. Compilation failed in require at p2.pm line 2. BEGIN failed--compilation aborted at p2.pm line 2. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. At the time of reporting this bug, I had some packages with use statements in the above order. I managed to resolv this. At this time my programm broke, because Class::DBI had changed the way, it was dealing with has_many. I wouldnt consider this behavior itself a bug (the *unanounced" change was an issue). It might be worth mentioning in the manpage as a requirement: A Class inheriting from Class::DBI, should declare that as early as possible. It must declare this, before using any other class, that has a has_* relationship with it

Wed Mar 01 10:16:19 2006 Guest - Correspondence added

On Sat Jun 18 05:41:00 2005, TMTM wrote: Show quoted text

> > main is a subclass of Class::DBI.

> > This is too contrived for my little brain. If you give an example that > uses classes other than 'main' I'll look at it again.

I have a less contrived example that get's this error : In my case I have several classes, but 1 fails to compile with 3.014, but works fine in 0.9x. I have 2 relevent classes - Task and TaskHistory.. TaskHistory has a Task on the TaskHistory task column Task has many TaskHistory on the TaskHistory task column Task has a last TaskHistory on the Task last_history column When compiling with latest CDBI get the following error : can't load Schedule::Chronic::Distributed::Task: Can't locate object method "meta_info" via package "Schedule::Chronic::Distributed::TaskHistory" at /usr/local/share/perl/5.8.4/Class/DBI/Relationship/HasMany.pm line 34. I'm guessing that the new has_many code doesn't like me having both a has_a and a has_many from one class to another, which is rather unhelpful, removing the extra has_a relationship isn't a particular hardship in this case but it does show a limitation in the new code that isn't documented. Relevent files attached

package Schedule::Chronic::Distributed::Task; =head1 NAME Schedule::Chronic::Distributed::Task - Class representing Task within Schedule::Chronic::Distributed =head1 SYNOPSIS use Schedule::Chronic::Distributed::Task; =head1 DESCRIPTION This class represents Tasks within the schedule, i.e. jobs that need doing, holding their state, arguments and related date and historical data. This class provides access to related data/classes such as the command, node, and a history of when the job was run, due, and it's previous states and errors. =cut use strict; use Time::Piece; use Time::Seconds; use base qw(Schedule::Chronic::Distributed::DBI); __PACKAGE__->table('task'); __PACKAGE__->columns(All => qw/id name command command_arguments priority created timeout min_interval max_interval retry_interval schedule_type notify_address current_status current_node current_due current_deadline last_status last_due last_deadline last_run last_completed last_node last_history description error/); __PACKAGE__->columns(Primary => 'id'); __PACKAGE__->columns(TEMP => qw/constraint_objects wait/); __PACKAGE__->has_many(requirements => 'Schedule::Chronic::Distributed::TaskRequirement'); __PACKAGE__->has_many(task_times => 'Schedule::Chronic::Distributed::TaskTimes'); __PACKAGE__->has_a(current_node => 'Schedule::Chronic::Distributed::Node'); __PACKAGE__->has_a(last_node => 'Schedule::Chronic::Distributed::Node'); __PACKAGE__->has_a(command => 'Schedule::Chronic::Distributed::Command'); __PACKAGE__->has_a(last_history => 'Schedule::Chronic::Distributed::TaskHistory'); __PACKAGE__->has_many(history => 'Schedule::Chronic::Distributed::TaskHistory',{ order_by => 'started' }); # loads of code goes here 1;

package Schedule::Chronic::Distributed::TaskHistory; use strict; use Time::Piece; use base qw(Schedule::Chronic::Distributed::DBI); __PACKAGE__->table('task_history'); __PACKAGE__->columns(All => qw/id task_name task command command_arguments status node priority error started finished due deadline/); __PACKAGE__->columns(Primary => 'id'); __PACKAGE__->has_a (task => 'Schedule::Chronic::Distributed::Task'); # code 1;

Wed Mar 01 10:16:21 2006 The RT System itself - Status changed from 'new' to 'open'

Wed Mar 01 10:21:12 2006 Guest - Correspondence added

On Wed Mar 01 10:16:19 2006, guest wrote: Show quoted text

> On Sat Jun 18 05:41:00 2005, TMTM wrote:

> > > main is a subclass of Class::DBI.

> > > > This is too contrived for my little brain. If you give an example that > > uses classes other than 'main' I'll look at it again.

> > I have a less contrived example that get's this error : > > In my case I have several classes, but 1 fails to compile with 3.014, > but works fine in 0.9x. > > I have 2 relevent classes - Task and TaskHistory.. > > TaskHistory has a Task on the TaskHistory task column > Task has many TaskHistory on the TaskHistory task column > Task has a last TaskHistory on the Task last_history column > > When compiling with latest CDBI get the following error : > can't load Schedule::Chronic::Distributed::Task: Can't locate object > method "meta_info" via package > "Schedule::Chronic::Distributed::TaskHistory" at > /usr/local/share/perl/5.8.4/Class/DBI/Relationship/HasMany.pm line 34. > > I'm guessing that the new has_many code doesn't like me having both a > has_a and a has_many from one class to another, which is rather > unhelpful, removing the extra has_a relationship isn't a particular > hardship in this case but it does show a limitation in the new code that > isn't documented. >

Just to confirm that removing the last_history relationship solves the problem - better than failing to compile, but not so good if I needed a relationship like that.

Wed Mar 01 11:36:33 2006 tony [...] kasei.com - Correspondence added

Subject:	Re: [rt.cpan.org #3305] has_many cause compilation error
Date:	Wed, 1 Mar 2006 16:36:06 +0000
To:	Guest via RT <bug-Class-DBI [...] rt.cpan.org>
From:	Tony Bowden <tony [...] kasei.com>

On Wed, Mar 01, 2006 at 10:16:21AM -0500, Guest via RT wrote: Show quoted text

> I'm guessing that the new has_many code doesn't like me having both a > has_a and a has_many from one class to another

This shouldn't be the problem. I can't see from glancing at your two packages where the problem might lie, but if you could turn them into a standalone test with which I can actually replicate the error, (i.e not referencing classes which aren't included, and ideally against an SQLite database) then I should be able to track it down and fix it. Thanks, Tony