[Zope-Coders] Zope test results

[Jeremy Hylton]

>>>>> "SH" == Shane Hathaway <shane@zope.com> writes:

  >> I just asked Jim about it and he thinks ZODB should ignore
  >> invalidations on objects that have a jar but not an oid.  I don't
  >> think that's the whole story, but it is part of the complete
  >> answer.

  SH> I'm thinking that perhaps it should actually be an error.  In
  SH> the past couple of hours we've discovered three places that set
  SH> _p_jar but not _p_oid.  Every one of them were wrong and
  SH> probably created strange bugs.

I agree with you, and Jim's rationale might be YAGNI.  I could change
Connection to assert that oid is not None, with the possibility that
we'll change it again if things don't go well with the alpha release.

  >> I wonder if we need to add a method on the ZODB Connection to
  >> "register" an object before the Transaction manager registers it.
  >> That might be a more explicit way to accomplsu what setting
  >> _p_jar does, and would allow the Connection to do whatever
  >> bookkeeping it needs to stay sane.

  SH> That sounds very interesting, though I could interpret that two
  SH> ways:

  SH> 1) Connection.register(object) will set the _p_jar (and perhaps
  SH>    _p_oid)
  SH> of the object, if it has not already been set, then call
  SH> get_transaction().register(object).  cPersistence will call
  SH> _p_jar.register() instead of get_transaction().register().

  SH> 2) Connection.register(object) will set the _p_jar (and perhaps
  SH>    _p_oid)
  SH> of the object.  It will simply return.  cPersistence will not
  SH> change.

  SH> I'd really like to see option 1, since in my own ZODB
  SH> experiments I've frequently had to patch Transaction.register().
  SH> If I could just override Connection.register() in my subclass,
  SH> the code would be much cleaner.  I think the performance impact
  SH> would be very small.

I had been thinking about option 2, but I hadn't given it much
thought.  What changes have you had to make to Transaction.register()?

Jeremy