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