Re: Live_Objects behavior depends on garbage collection timing

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

Sorry about not clarifying, but the card object remains "Live" even if I don't keep a local var pointed to it, and even if I return "1" from the block. That's why I suspect has_a as the culprit. 

Here is a revised version of example 4:

-----------
do {
	Class::DBI::card->retrieve(25189);
	if (my $hh=Class::DBI::html->retrieve(25189)) {
	$hh->html;
	}
	1;
};
print STDERR Class::DBI->dump_object_index();

----------
output:

[max@localhost tmp]# perl dbi_cache_test.pl
$VAR1 = {
          'Class::DBI::html|cid=25189' => undef,
          'Class::DBI::card|cid=25189' => bless( {
                                                          'cid' => '25189'
                                                        }, 'Class::DBI::card' )
        };


max



On Fri, Jul 09, 2004 at 04:24:36PM -0400, Perrin Harkins wrote:
> On Fri, 2004-07-09 at 15:12, Siamak Pazirandeh wrote:
> > ex 1: This is the original case where the $user object persists.  This
> > is the behavior I got on 5.8.0 and 5.8.2
> > 
> > do { my $user = Class::DBI::users->retrieve(1); };
> > print STDERR Class::DBI->dump_object_index();
> > 
> > $VAR1 = {
> >           'Class::DBI::users|user_id=1' => bless( {
> >                                                            'user_id' => '1'
> >                                                          }, 'Class::DBI::users' )
> >         };
> [...]
> > ex 4: This is the more serious case, which comes up with "has_a"
> > relationships. probably the same issue as demonstrated in example 1,
> > but actually implemented within the has_a behaviour:
> > 
> > 
> > In the following example, Class::DBI::html defines a "has_a"
> > relationship to Class::DBI::card, on the primary key. You'll note that
> > the card object persists. This is the original case which caused me to
> > look into the issue. Very, Very subtle, but allows the object to
> > remain as a Live_Object somehow. 
> > 
> > do {
> > my $card2=Class::DBI::card->retrieve(25189);
> > 	if (my $hh=Class::DBI::html->retrieve(25189)) {
> > 	$hh->html;
> > 	}
> > };
> > print STDERR Class::DBI->dump_object_index();
> > 
> > $VAR1 = {
> >           'Class::DBI::html|cid=25189' => undef,
> >           'Class::DBI::card|cid=25189' => bless( {
> >                                                           'cid' => '25189'
> >                                                         }, 'Class::DBI::card' )
> >         };
> 
> This is the same as #1, isn't it?  What happens if you drop that
> assignment to $card2 in the beginning?  That should make it the same as
> example #3.
> 
> My opinion at the moment is that this is looking potentially too
> difficult for programmers to manage.  If normal perl constructs commonly
> result in scoping problems, we should remove the single instance
> feature.  Other opinions?
> 
> - Perrin
>