in reply to Hash references moving between modules

For starters, I don't understand both Bio:DB::Das::Chado and Bio::DB::Das::Chado::Segment being subclasses of Bio::Root::Root ... but besides that I also don't think this line is doing what you want:

return $self->Bio::DB::Das::Chado::Segment->new($name,$self,$start,$end);

shouldn't that just be: 

return Bio::DB::Das::Chado::Segment->new($name,$self,$start,$end);

[download]

Other than that, are you sure your sql is returning results? If your sql fails, $cvterm_id will never be converted to a hash reference (it will stay a plain scalar) and your code downstream will fail. You probably want something like this to protect the code downstream (or you could check if you have a hash downline): 

my $cvterm_id = {} ;  # this scalar is  a hashref
while (my $hashref = $sth->fetchrow_hashref) {
    $$cvterm_id{$$hashref{termname}} = $$hashref{cvterm_id};
}

[download]

Then at least %termhash will be a hash but quite possibly an empty one if the sql fails.

-derby

Replies are listed 'Best First'.
Re: Re: Hash references moving between modules
by scain (Curate) on Jan 10, 2003 at 18:18 UTC
    Ack, that is what I get for trying to simplify too much. First, Bio::Root::Root is the main class from which most BioPerl objects inherit.

    The first line you mention didn't really look like that in my code, it was

    return $self->_segclass->new($name,$self,$start,$end);

    [download]
    Where _segclass is a private method that returns the string 'Bio::DB::Das::Chado::Segment'. I was trying to hard to trim things down and simplified one thing to make it wrong.

    It is a good point that I should be checking for returned results. In this case, I know that they are from previous debugging. Nevertheless, I will add the = {}; because that is a good idea.

    Thanks,

    Scott
    Project coordinator of the Generic Model Organism Database Project

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom