A persistent problem -- monkey patch related?
I asked this question to the list a while back, but the responses I got were a bit off-point. Sad to say, the issue remains unresolved. I have made some extensive mods to UserFolder and installed them with a monkey patch. The monkey patch lives in the Products folder. The __init__().py associated with the folder imports User.py, defines the methods to be changed (e.g., foo(self) defined outside a class, then imports AccssControl and InitializeClass from Globals, assigns the new method to the associated old method name in UserFolder, and then calls InitializeClass. I chose this approach because it looked to have the least impact on the existing system, but now I am not so sure. I've been getting _p_oid errors when the OODB is backing out of a transaction. Dieter has opined that it's a Zope bug, but I am not so sure. I suspect that something I have done in the monkeypatch has triggered the problem. My patch code uses PersistentMapping() and expects that the system does the right thing with respect to persistence in the new methods even though they are patched in. Can anyone shed light on the issue: Is persistence inherited by monkey patched methods?
Dennis Allison wrote:
I asked this question to the list a while back, but the responses I got were a bit off-point. Sad to say, the issue remains unresolved.
I have made some extensive mods to UserFolder and installed them with a monkey patch.
Why not just subclass and have your own type of UserFolder? SimpleUserFolder makes this pretty easy ;-)
I chose this approach because it looked to have the least impact on the existing system, but now I am not so sure. I've been getting _p_oid errors when the OODB is backing out of a transaction.
Any chance of seeing what those errors are?
that it's a Zope bug, but I am not so sure. I suspect that something I have done in the monkeypatch has triggered the problem. My patch code uses PersistentMapping() and expects that the system does the right thing with respect to persistence in the new methods even though they are patched in.
Hmmm, I wonder where in the transaction setup that PersistentMapping is getting twiddled with?
Can anyone shed light on the issue: Is persistence inherited by monkey patched methods?
Nope, wouldn't have thought so. Can you state your problem, there might be a better way than your current solution which could rule it out as the source of these problems... cheers, Chris
Thanks for your comments Chris. The '_p_oid' problem seems to be a different, but possibly related problem to the persistence problem. With Jeremy's help I have modified the error logging portion of my Zope to help identify the problem. Current thinking is that it is a bug in Zope, but we need more information. The persistence problem manifests itself by disappearing data (sometimes). My patch changes the data structure used for acl_users. And, yeah, it woulda been better to strt afresh, but that would mean ripping out a lot of code which sorta grew and the associated debug problem. So a patch is a better choice until it's time to rewrite the whole thing. I am very skeptical about monkey patched methods in Zope behaving the right way vis a vis persistence. When I next take things down, I will replace UserFolder with my own version which should resolve the issue, but I am stil curious about what works and what doesn't with respect to persistence. On Fri, 23 Jan 2004, Chris Withers wrote:
Dennis Allison wrote:
I asked this question to the list a while back, but the responses I got were a bit off-point. Sad to say, the issue remains unresolved.
I have made some extensive mods to UserFolder and installed them with a monkey patch.
Why not just subclass and have your own type of UserFolder? SimpleUserFolder makes this pretty easy ;-)
I chose this approach because it looked to have the least impact on the existing system, but now I am not so sure. I've been getting _p_oid errors when the OODB is backing out of a transaction.
Any chance of seeing what those errors are?
that it's a Zope bug, but I am not so sure. I suspect that something I have done in the monkeypatch has triggered the problem. My patch code uses PersistentMapping() and expects that the system does the right thing with respect to persistence in the new methods even though they are patched in.
Hmmm, I wonder where in the transaction setup that PersistentMapping is getting twiddled with?
Can anyone shed light on the issue: Is persistence inherited by monkey patched methods?
Nope, wouldn't have thought so. Can you state your problem, there might be a better way than your current solution which could rule it out as the source of these problems...
cheers,
Chris
Dennis Allison wrote at 2004-1-23 07:38 -0800:
... The persistence problem manifests itself by disappearing data (sometimes).
Which data disappears? You are aware of the perilious modification of mutable attributes?
I am very skeptical about monkey patched methods in Zope behaving the right way vis a vis persistence.
Monkey patches do not affect the way how persistence works. You should see the same behaviour when you methods were not patched but "original"... -- Dieter
The observed behavior (as always, transient and irreproducable from test cases) is that the contents of a PersitentMapping object disappears. The underlying structure is a PersistentMapping of PersistentMappings of User objects. My understanding is that the PersistentMapping wrapper handles the black magic properly. As for the perilious modification of mutable attributes, I am certainly aware of the issue--in fact, that's why I am so concerned about the monkey patch issue as it is in the monkey patch code that the PersistentMapping constructor is called, etc. On Fri, 23 Jan 2004, Dieter Maurer wrote:
Dennis Allison wrote at 2004-1-23 07:38 -0800:
... The persistence problem manifests itself by disappearing data (sometimes).
Which data disappears?
You are aware of the perilious modification of mutable attributes?
I am very skeptical about monkey patched methods in Zope behaving the right way vis a vis persistence.
Monkey patches do not affect the way how persistence works. You should see the same behaviour when you methods were not patched but "original"...
-- Dieter
Dennis Allison wrote at 2004-1-23 13:13 -0800:
The observed behavior (as always, transient and irreproducable from test cases) is that the contents of a PersitentMapping object disappears. The underlying structure is a PersistentMapping of PersistentMappings of User objects. My understanding is that the PersistentMapping wrapper handles the black magic properly. As for the perilious modification of mutable attributes, I am certainly aware of the issue--in fact, that's why I am so concerned about the monkey patch issue as it is in the monkey patch code that the PersistentMapping constructor is called, etc.
Recently, a packing bug has been detected ("FileStorage") which can lead to data loss. It is triggered when a pack tries to pack to a time before the pack time of an earlier pack. When you detect the loss before history information has been removed by a pack, you can reconstruct the content of earlier versions (and at least determine when the loss occured -- this may give some hints with respect to the cause). I posted some (low level!) routines to "mailto:zope-dev@zope.org" or "mailto:zodb-dev@zope.org" that makes this a bit easier (--> archives). Almost surely (I am convinced, but I know your trust in me is limited :-) ), monkey patching does not affect whether or not persistent object changes are lost... -- Dieter
Thanks for the information. For the moment I will assume the monkey patch works and no longer worry. BTW, what happens is that the data structure (a PersistentMapping of a PeristentMapping of Objects) populated by XMLRPC is present for a while but diappear. While I have not been able to confirm it, it seems to be correlated to system restart. On Fri, 23 Jan 2004, Dieter Maurer wrote:
Dennis Allison wrote at 2004-1-23 07:38 -0800:
... The persistence problem manifests itself by disappearing data (sometimes).
Which data disappears?
You are aware of the perilious modification of mutable attributes?
I am very skeptical about monkey patched methods in Zope behaving the right way vis a vis persistence.
Monkey patches do not affect the way how persistence works. You should see the same behaviour when you methods were not patched but "original"...
-- Dieter
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Dennis Allison wrote at 2004-1-23 13:30 -0800:
BTW, what happens is that the data structure (a PersistentMapping of a PeristentMapping of Objects) populated by XMLRPC is present for a while but diappear. While I have not been able to confirm it, it seems to be correlated to system restart.
This almost looks as if the PersistentMapping were contained in a non-persistent object which is unaware of the PersistentMapping's creation. -- Dieter
That was the reason I was suspecting the monkey patching. But you have convinced me that it is not likely to be the source of the problem. On Sat, 24 Jan 2004, Dieter Maurer wrote:
Dennis Allison wrote at 2004-1-23 13:30 -0800:
BTW, what happens is that the data structure (a PersistentMapping of a PeristentMapping of Objects) populated by XMLRPC is present for a while but diappear. While I have not been able to confirm it, it seems to be correlated to system restart.
This almost looks as if the PersistentMapping were contained in a non-persistent object which is unaware of the PersistentMapping's creation.
-- Dieter
participants (3)
-
Chris Withers -
Dennis Allison -
Dieter Maurer