When do Class::DBI objects lose their values?

[prev] [thread] [next] [Date index for 2004/08/13]

No, it was a hash ref.

What seemed to be causing me problems was that my domain objects were
continuing to point at Class::DBI objects after (and this I can't
fathom) those Class::DBI objects became "stale". Unfortunately, I don't
understand what "stale" means precisely, but a Data::Dumper dump only
shows $object->{attribute}s for those columns which happen to have
non-zero values, and it happened after an update, a commit, and a cache
purge.

So, when, in the normal operation of Class::DBI, would Class::DBI
objects lose all their 'true' values including their id, but none of
their zero values?=20

-----Original Message-----
From: Perrin Harkins [mailto:perrin@xxxx.xxx]=20
Sent: 10 August 2004 19:29
To: Ian McDonald-ONLINE
Cc: brano@xxxxxxxxxx.xx; cdbi-talk@xxxxxx.xxxxx.xxx
Subject: RE: No way to instantiate two related CDBI classes at
once,isthere?


On Tue, 2004-08-10 at 11:53, Ian McDonald-ONLINE wrote:
> I'm not so bothered about avoiding the need to create an accessor; the
> method which creates both objects will sit outside either.
>=20
> But I can't get it to work.

Probably because I got the construct() call wrong.  It should be a hash
ref:

sub retrieve_with_bar {
    my ($class, $id) =3D @_;
    my $sth =3D $class->sq_get_both();
    $sth->execute($id);
    my $row =3D $sth->fetchrow_arrayref();
    my $foo =3D Foo->construct({
                              id    =3D> $row->[0],
                              other =3D> $row->[1],   =20
                             });
    my $bar =3D Bar->construct({
                              id    =3D> $row->[2],
                              other =3D> $row->[3],   =20
                             });
    $foo->{'_bar_object'} =3D $bar;
    return $foo;
}

Be sure to name the columns correctly.

> I've tried calling $class->sth_to_objects($sth) or $class->construct
> repeatedly for each class, and although the first resulting object is=20=

> fine, the second doesn't contain all the fields from the initiating=20
> hash
> - least of all its primary key.

sth_to_objects() uses the column names (from DBI) to know where to put
things, so that isn't going to work.  That's why I used construct()
instead.

> It seems to be pulling a broken something out of Live_Objects.

I think that's just a red herring.  The bad construct() call is the
problem.

> 526:            unless (defined($obj =3D $Live_Objects{$obj_key})) {
>   DB<5> p $obj_key Conquer::Persist::ActiveRecord::PC|cha_id=3D55
>=20
>   DB<7> p %Live_Objects
>=20
>   DB<11> p Dumper(%Class::DBI::Live_Objects)

It's not a global, it's a closure var.

>   DB<12> p $Live_Objects{$obj_key}
> Use of uninitialized value in print at (eval
> 83)[/usr/local/perl-5.6.1/lib/perl5/5.6.1/perl5db.pl:1521] line 2.

Doesn't that auto-vivify?  I think you will cause it to pass the
defined() test by doing this.

- Perrin


http://www.bbc.co.uk/ - World Wide Wonderland

This e-mail (and any attachments) is confidential and may contain
personal views which are not the views of the BBC unless specifically
stated.
If you have received it in error, please delete it from your system.=20
Do not use, copy or disclose the information in any way nor act in
reliance on it and notify the sender immediately. Please note that the
BBC monitors e-mails sent or received.=20
Further communication will signify your consent to this.