Re: [CDBI] Subroutine redefined

[prev] [thread] [next] [Date index for 2004/09/03]

On Fri, Sep 03, 2004 at 03:48:59PM -0400, Sean Quinlan wrote:
> My contention though is that the names, and the documentation, would
> seem to lead people to set it up incorrectly.

If you can improve the documentation, I know that Tony will happily
review, and usu. includes, patches. I've submitted a few myself as I
went through the learning curve.


> > > I also have a mnemonic problem - an applicant might have a reviewer
> > > ... but they might not have been assigned one yet, so wouldn't the
> > > has_a cause a problem at run time?!?
> > 
> > No. See yesterday's discussion that Peter Pimley started. There appears
> > to be no restriction by either CDBI or SQL that dictates that a has_a
> > must have a corresponding record. The foreign key field appears to fine
> > if left undef.
> 
> Hmmm. Even if you define a constraint in the database for the foreign
> key field that requires the parent to exist?

Well no, but then you're defining a restriction. My point was that there
is nothing in SQL or CDBI that requires such a restriction to exist.
This is starting to get into normalization and good database design.
CDBI, like Perl, is not going to enforce you to do it the "right" way.
It's up to you to use it to your best ability.


> I don't mean to say that the methods aren't useful. I'm just suggesting
> that the names don't really seem to indicate the appropriate usage, or
> the difference between the two methods. I'll re-read the docs again and
> play with them some and maybe it will make more sense to me. But that is
> my first impression.

I think these are valid points. I don't know enough of the history of
this project to say whether there is a reason for those names or their
behaviors. Perhaps some of the elders will address your point.


> > > But changing _that_ definition to:
> > > BioInfo::DB::Qualifiers->might_have(Student => 'BioInfo::DB::Students');
> > 
> > might_have must be a bit less picky about the columns not existing.
> 
> Odd

Upon further reflection I realized that you are essentially defining a
new column when you use might_have. has_a says that an existing column
is actually another type. If that column doesn't exist, CDBI generates
an error.


> > > <sigh> ... I'm going to have to read a lot of source code this weekend,
> > > eh? ;-}
> > 
> > It takes awhile to get familiar with CDBI. Read the wiki and keep
> > rereading the docs--they'll eventually start to make more sense to you.
> 
> Docs shouldn't, IMHO, have to be reread a bunch of times to make sense.
> Of course, I've been told that a lot of the docs I've written which
> seemed to make perfect sense to me, were mind-bendingly unclear. =D

:) I don't think anyone on this list is going to argue that the docs are
perfect. IMHO, they require a too intimate knowledge of how CDBI works.
As you gain that understanding, the docs will make better sense. Please
revise them as you find better ways to explain how this module works.


William

        -- 
        Knowmad Services Inc.
http://www.knowmad.com