#22 fix dangling references in listattrs

MiddleKit (8)
Jason Hildebrand

Assume the following model:

Class Attribute Type
container Container
name string

name string
items list of Item

Now suppose there are two instances of Item (Item.1 and
Item.2), one
instance of container (Container.1) and both Items are
contained in
Container.1. That is, Item.1.container() ==
Item.2.container() ==
Container.1 (please excuse the abuse of notation).

Now I do something like:

c = store.fetchObject( 'Container', 1 )
items = c.items()
print len(items) # should be two

# delete one of the items
store.deleteObject( items[0] )

print len( c.items() ) # should be one, but is
still two

The reason is that the Container object caches its list
of Items
internally as self._items, but after the Item is
deleted, it doesn't
know to refresh its list. So, short of calling
store.clear() to toss
out all cached objects (or restarting the app server),
I can't convince
Container.1 that it now contains only one Item. If I
try to reference
the "ghost" Item, I get a dangling reference error
(which is correct).

Is this simply a matter of MiddleKit not being
complete? Or is this
problem somehow unique to me?

After spending a considerable amount of time going
through the MK
source, I suspect the former. If this is the case,
I'll take a crack at
implementing the correct behaviour (now that I finally
grok what's going
on, it doesn't seem too difficult to fix).

I didn't notice this problem until recently, since I
was instantiating
a new store on every request (which is dumb). Now I
have one global
store, which is the way (I think) MiddleKit was
intended to be used
(although the docs don't really say much about this --
it would be good
to add some of these "big picture" assumptions to the
user guide).

The attached patch fixes this problem.

Implementation: If an object such as "Item" is deleted,
it checks all
objects which it references (like Container), and gets
each of these
objects to remove it from any list attributes they
might have.


  • Patch against 0.7b2

  • Updated patch against 0.7b2

  • Logged In: YES

    Updated the patch. A few last minute changes to the
    docstrings didn't use real tabs.

  • Geoff Talvola
    Geoff Talvola

    • assigned_to: gtalvola --> echuck
  • Logged In: YES

    Hi Chuck,

    I finally got around to optimizing this patch a bit; the
    logic is the same, but it now avoids pulling in any objects
    from the database. I also made a small optimization to the
    delete code which is included in this patch (more below).
    I think it's ready to go in.

    Just upgraded to 0.7 -- huge improvement in delete
    performance! I tested deleting a large hierarchy of
    objects; it took 63 seconds with 0.7b2,
    only 1.8 seconds with 0.7. After improving my patch it took
    1.1 seconds.

    In an optimizing mood, I then noticed that since the results
    of the MiddleObject.backObjRefAttrs() function don't depend
    on the object itself,
    this function can be moved to the Klass class. This means
    that the calculation
    is only performed once per class (and then cached) instead
    of once per object. I've included this change in the patch,

    This further reduced my test case time to about 0.9 seconds.
    Not a huge improvement, but still worth it IMO, especially
    since it doesn't add any
    complexity to the code.

  • Updated patch against 0.7

  • Geoff Talvola
    Geoff Talvola

    Logged In: YES

    This patch unfortunately doesn't apply cleanly to
    Webware CVS due to changes made in the meantime.
    Any chance you could update it so I can patch CVS?

  • Logged In: YES

    Hi Geoff & Chuck

    I don't use CVS head, which somewhat hinders my ability to
    test the patch,
    but I will check out CVS head and update the patch, and try
    to do a bit of testing. I'll likely do this tomorrow or
    Saturday morning.

  • Updated patch against CVS head (2002-09-27), and added test case

  • Logged In: YES

    I've updated the patch against CVS head, and I added a test
    case to the MiddleKit test suite. Hope this helps.

  • Updated patch against CVS head (2002-09-25), added test case

  • Logged In: YES

    This has been fixed in CVS; this bug report is obselete.

    • status: open --> closed-invalid