RE: When do Class::DBI objects lose their values?

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

As always seems to happen, I notice something just after sending an
email to the list.

This is the sequence of events:
1. Instantiate a couple of Class::DBI objects.
2. Store them with ->update.
3. *Don't* purge the object cache.
4. Try to instantiate the a Class::DBI object for one of the same rows,
with ->construct( $hashref).
	(The hashref is validly produced from an SQL call, but construct
doesn't know that.)

The resulting Class::DBI object, when inspected under Data::Dumper, only
includes those
columns from the database which have value zero.

Is this expected behaviour with a well-known explanation, a known bug,
or a new bug?

If it's a new bug, I'll put together a script to replicate it.

-----Original Message-----
From: Ian McDonald-ONLINE=20
Sent: 13 August 2004 19:16
To: 'Perrin Harkins'
Cc: brano@xxxxxxxxxx.xx; cdbi-talk@xxxxxx.xxxxx.xxx
Subject: When do Class::DBI objects lose their values?


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=20=

> 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=20
> 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.