Re: More object index weirdness

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

On Thu, 2004-09-16 at 12:19, William McKee wrote:
> I have a relationship like this in ClassA.pm:
> 
>   __PACKAGE__->might_have (my_b => 'ClassB' => qr/limit/)
> 
> 
> In my before_update trigger, I do the following:
> 
>   $class->my_b->delete;

$class still has a reference to the object in $class{'_my_b_object'}. 
You can see this in the MightHave code.  So, if you keep $class around,
you will still have the ClassB object in memory.

> On the next operation, I'm still seeing the "old" record coming back out
> of the object index.

If $class goes out of scope, and then you load it again, you should not
get anything back from calling ->my_b.  However, it has to truly go out
of scope (or get explicitly cleared).  This will not do it:

$class = ClassA->retrieve(1);
$class = ClassA->retrieve(1); # doesn't actually reload

You would need to actually undef $class between calls to make it go out
of scope.  Otherwise, you just get the same object back again.

> So before 0.96 and the object index, I would have had multiple objects
> in memory.

Right, and now instead you get multiple references to the same object.

> OK, I see the value that the index brings. It's definitely
> going to make my code cleaner. Getting used to it though is like getting
> used to coding with 'use strict'.

I suppose there's no way to make everyone happy.  There were complaints
before this feature was introduced about the fact that fetching the same
object twice gave two different object instances.  Now there are
complaints about people not getting two different object instances.  I
do think we should default the object index feature to OFF for the next
release.

> > That's essentially the whole point of the index: if you have an existing
> > object, it will not make another one for the same key.  It will give you
> > back the existing one.
> 
> So if I don't want it to do that I need to make darn sure that I'm not
> keeping a copy of the old record hanging around in memory.

Correct.

> > In-memory changes in one process will never affect the memory of another
> > process.  Deleting something in the database deletes it for everyone of
> > course (although people sometimes get confused by isolation levels,
> > especially with InnoDB tables).
> 
> If I understand this correctly, it would mean that if I were unknowingly
> keeping objects in memory between requests (given a mod_perl
> environment) that database updates in Process A would not be seen by
> Process B. To the user/programmer this would appear as though the
> database were not being updated when in fact it was. That's spooky and
> considerably confusing for folks coming to CDBI (thus my problems).

It is a potential issue, but it actually has nothing to do with
Class::DBI, or even Perl.  You can do this in any programming language. 
For the amount of time that you keep data from the database in memory in
local variables, you are out of sync with the database.  Changes that
happen in the database don't get reflected in your variables.  This is
just the nature of database programmming.

- Perrin