Hooking persistent.Persistent.__setstate__ was Re: [ZODB-Dev] Analyzing a ZODB.

[Alan Runyan]

Here is something more ZODB and less Zope related (kinda).

 I was talking with Benji a few weeks ago about a problem that should
 be easy to debug but was not.  Here is the scenerio:

  - Customer has software on a remote machine.  They are seeing
  unnecessary transaction commits.  Just like the guy 'Analyzing a ZODB'.

  - Customer is completely incapable of doing anything other than putting
  a script on the filesystem.

  - Benji and I thought about it and he proposed 'the simplest thing that
  c/should work, monkey patch persistent.__setstate__' so that I could see
  what objects were being mutated.

  - Unfortunately ZODB 3.x does not have a Python fallback of
  persistent.Persistent -- its in C.  The customer did not have a C compiler
  on their box.

 IIRC how I solved it was increase ZEO event log to see the oid's.  Then I
 walked him through loading the oid up to see what object was being
 mutated.  It was more painful than it should have been.

 Question:  Is it possible for ZODB 3.9 to have a pure python
 implementation of persistent.Persistent?  Maybe this would be a good
 ZODB GSOC project?

 Notes:

  - ZODB 4.x did have a pure python impl of persistent.Persistent
 but that project did not make it into production.

  - Seemingly Jim F. said there was a 'best practice' in writing C
 extensions in Python, first write reference impl in Python and to
 write tests around the impl.  Then re-implement in C.  ZODB 3.x,
 never had this 'best practice' put into play.

  - increasing zeo server log level and watching oid's being changed
 is sort-of the equivalent of turning on RDBMS logging to see SQL
 stmt's being executed.  Unfortunately I believe without having a
 hook in persistent.Persistent we can never really get that level
 of granularity (i.e. __getattribute__ is only accessible in client)
 with only ZEO server logs.

  - We could "monkey patch" the subclasses that use persistent.
 But in the world of non-Zope2 applications usually there are very
 thin classes that may not have any common base class other than
 persistent.Persistent.

 This is a transparent plea for a "new feature".  But I believe it would
 significantly help people writing ZODB applications.

 Maybe people should always have a base class that you override
 those methods which delegate to persistent.Persistent.  i.e.
 class MyMixin(persistent.Persistent) and mixin MyMixin
 instead of mixin persistent.Persistent directly?  Then
 you can instrument the MyMixin with the logging?

 Another GSOC idea: Best Practices of ZODB Programming.

 cheers

 --
 Alan Runyan
 Enfold Systems, Inc.
 http://www.enfoldsystems.com/
 phone: +1.713.942.2377x111
 fax: +1.832.201.8856



-- 
Alan Runyan
Enfold Systems, Inc.
http://www.enfoldsystems.com/
phone: +1.713.942.2377x111
fax: +1.832.201.8856