I've just been introduced to Class::DBI. While I like it lots in general,
it seems like it's missing one obvious feature, but being new to the
module I think it's more likely I'm missing the point than Class::DBI is
missing a feature.
Here's the situation.
I set up two classes, like so:
package Survey;
use base 'My::DBI';
use strict;
__PACKAGE__->table('surveys');
__PACKAGE__->columns(Primary => 'survey_id');
__PACKAGE__->columns(All => qw(title text));
__PACKAGE__->has_many('questions', Survey::Question => 'survey_id');
package Survey::Question;
use base 'My::DBI';
use strict;
__PACKAGE__->table('questions');
__PACKAGE__->columns(Primary => 'question_id');
__PACKAGE__->columns(All => qw(title text));
(the My::DBI class has all the db connection details in it and is a
subclass of Class::DBI, so I don't have to keep that in the
sub-classes. also, there's a class for answers as well but let's
leave that out for clarity.)
So what I wanted to be able to do is this:
my $survey = Survey->retrieve($survey_id);
## get question data from somewhere
$survey->add_question(\%question_data);
where the 'add_question' method is created automagically in the same way
the 'questions' method is created by Class::DBI, rather than having to do
this:
my $survey = Survey->retrieve($survey_id);
## get question data
my $question = Survey::Question->create(\%question_data);
$question->survey($survey);
which is, as far as I can tell, the only way to add a child object to a
parent object. (child being the 'hasa' end of the relationship and parent
being the 'has_many' end.) I don't like this because I have to hard-code
the name of the child class somewhere else besides the has_many
initialization statement, and that feels messy. It also just feels
backwards.
I've overridden 'has_many' with a version that does what I want, but my
question is, am I missing a trick? Is there a standard idiom for doing
things more or less the way I wanted to within the existing Class::DBI
framework?
michael
