Re: oracle woes

[prev] [thread] [next] [Date index for 2004/07/14]

On Tue, 2004-07-13 at 23:48, Randal L. Schwartz wrote:
> But the very same code under DBD::Oracle, I get:
> 
>     -> execute for DBD::Oracle::st (DBIx::ContextualFetch::st=HASH(0x6b926c)~0x6c4c14 My::DB::List=HASH(0x67c1fc) My::DB::Person=HASH(0x6abc50))
>     -- DBI::END
> 
> and then everything unwinds, die'ing with:
> 
>         Can't bind a reference (My::DB::List=HASH(0x67c1fc)) at /ssa/homedirs/02/48/merlyn/.cpan/lib/perl5/site_perl/5.8.3/DBIx/ContextualFetch.pm line 51.
> 
> How come?  Does DBD::Oracle not know how to view the ->id column
> to get to the real value for the SQL?  And if so, how should I have
> written this?

Sounds like a stringification problem.  Maybe DBD::Oracle is not
recognizing your ID as a string and forcing the context on your bind
variables correctly.  I also recall a bit of uncertainty as to whether
or not it was okay to make primary key columns have has_a()
relationships.  As a workaround, try giving the has_a() methods
different names from the accessors by using the accessor_name() hook. 
Or, write the has_a methods manually, just to test:

sub get_person {
    my $self = shift;
    return My::DB::Person->retrieve( $self->person() );
}

- Perrin