[PEAK] EntityDM._thunk method
cogumbreiro at gmail.com
Wed Jul 20 21:46:48 EDT 2005
Here's a simplified version of the code, in order for it to work:
foo = self.FooDM.newItem ()
bar = self.BarDM.newItem ()
bar.foo = foo
self.BarDM.flush () #
self.FooDM.flush () #
self.assertEqual (len (self.BarDM), 0)
self.assertEqual (len (self.FooDM), 0)
 must be called otherwise the self.FooDM._thunk will be called
 must be called otherwise len() will get the wrong value because
the objects - FooDM triggers BarDM into remove 'bar' - will only be
removed on the end of the transaction.
My first question is, why do I need to call ?
Since my len() is basically returns the value from `self.db ("SELECT
COUNT(*) FROM Table")`, is there anyway to enforce that flush be
called and thus it gets a real value?
On 7/21/05, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 12:08 AM 7/21/2005 +0000, Tiago Cogumbreiro wrote:
> >In a testcase I am creating two objects one depends on the other, in
> >the same transaction I am removing the first, then the '_thunk' method
> >is called and a NotImplementedError is raised.
> >What is this method for?
> _thunk() is for implementing cross-database imports or references. It's
> called when a DM needs to know what OID an object should be saved under,
> but the object doesn't belong to that DM.
> >Is this testcase a wrong one?
> When you delete an object from a DM, it no longer "belongs" to that
> DM. Probably the object you're not deleting is trying to save a reference
> to the deleted object, but since the object is deleted, _thunk() gets
> called to effectively resurrect it.
> It may be that the oidFor() method should be extended to handle the case
> where an object does not belong to any DM, and "adopt" it for that DM
> (effectively resurrecting it if it was deleted). However, it's probably
> also the case that your test is doing something you don't really intend it
> to. For example, it may be that you need to delete the reference to the
> deleted object from the non-deleted object being saved, rather than just
> deleting the object itself.
More information about the PEAK