Re: More object index weirdness

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

On Thu, Sep 16, 2004 at 11:30:00AM -0400, Perrin Harkins wrote:
> Okay.  What does the code where you delete it look like?  I'm not sure
> if your idea of deleting the object is the same as mine, because in mine
> there is no way you could reload it after deleting it.

OK, what I'm doing is deleting a might_have record under certain
conditions in a before_update trigger. Given the following tables:

TableA (
    a_id integer primary key
);
TableB (
   a_id integer primary key
   limit integer
);

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;


On the next operation, I'm still seeing the "old" record coming back out
of the object index. My workaround is to add the following line before
the delete:

  $class->my_b->remove_from_object_index;

UPDATE: Upon further testing I have discovered that I can now safely
remove that line and my tests are passing. I guess that I finally
exorcised the object that was sticking around in memory and causing the
index to be maintained. I wish I knew which modification it was <g>.


> > Does the index not get refreshed when a record is reloaded?
> 
> The index never gets refreshed in any situation.  An object is either in
> memory or not, and if it is in memory, the index has a reference to it.

OK, now it's becoming clear.


> 
> > If not, then it would seem to me that the index is acting more like a
> > cache.
> 
> No, your code is acting like a cache and the index is making that
> visible to you.

So before 0.96 and the object index, I would have had multiple objects
in memory. 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 it could be the case that existing objects take
> > precedence over incoming objects when an object is already in the index.
> 
> 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.


> Could be an accidental closure created by defining a lexical outside of
> a sub where you use that lexical.

That's a good thought. I've added it along with some other strands of
our conversation to the CommonProblems recipe on the wiki.


> > But that would still mean I'm keeping
> > objects around in memory and simply doing a remove_object_from_index in
> > process A wouldn't affect process B (would it?).
> 
> 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).


Thanks,
William

        -- 
        Knowmad Services Inc.
http://www.knowmad.com