Re: create bug

[prev] [thread] [next] [Date index for 2005/05/18]

On Wed, 2005-05-18 at 16:49 +0200, Hartmaier Alexander wrote:
> What I'm doing is a ->create followed by a method call on a deflated column
> which returns another object.
> The created object is dropped according to the docs after creation to
> prevent changes by other processes etc. to be overwritten.
> It seems that the object is only reloaded if a column is accessed in a
> 'scalar way' and not if it has to be deflated...
> 
> When using the Music::DBI example it would by something like this:
> 
> my $obj_cd = Music::CD->create ({cdid => 1, artist => 1,  title =>
> 'October', year => 1980});
> 
> $obj_cd->artist->sub; # sub would be the name for the custom sub defined for
> the class Music::Artist.
> 
> Is that enough example?

Combined with your previous posts showing the class definition and the
method giving you trouble, it is.  The problem is a result of a
Class::DBI limitation (or bug if you prefer), but it's documented: you
are defining a has_a() relationship on a column that is part of your
primary key.

There are two workarounds I've used for this.  The first is to drop the
object and reload it.  Make sure you undef the object or remove it from
the live objects index.

The other fix is to make your own simple has_a().  This is usually what
I do.  For example:

sub device {
    my $self = shift; 
    return DeviceClass->retrieve($self->_device_fk_accessor());
}

See http://wiki.class-dbi.com/index.cgi?OverridingAutogeneratedAccessors
for info on the accessor I used there.

- Perrin