Skip Menu |
 

This queue is for tickets about the Class-DBI CPAN distribution.

Report information
The Basics
Id: 3305
Status: open
Priority: 0/
Queue: Class-DBI

People
Owner: Nobody in particular
Requestors: martin [...] hybyte.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.93
Fixed in: (no value)



Subject: has_many cause compilation error
Download (untitled) / with headers
text/plain 347b
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"); '
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:
Download (untitled) / with headers
text/plain 690b
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
Download (untitled) / with headers
text/plain 335b
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 ...
[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.
Download (untitled) / with headers
text/plain 177b
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
Download (untitled) / with headers
text/plain 1.2k
[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
Download (untitled) / with headers
text/plain 1.1k
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
Download Task.pm
text/x-perl 1.7k
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;
Download TaskHistory.pm
text/x-perl 427b
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;
Download (untitled) / with headers
text/plain 1.3k
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.
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>
Download (untitled) / with headers
text/plain 547b
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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.