Re: [Zope] Re: Zope Persistence (was: XML-RPC within ZOPE)

2005-12-18 Thread Michael Dunstan
On 12/19/05, Jan-Ole Esleben <[EMAIL PROTECTED]> wrote: > However, even if > it is only the docs that are lacking I think it would be sensible to > acknowledge that as a problem. Zope 3 is the literate child of Zope 2. ___ Zope maillist - Zope@zope.org

Re: [Zope] Re: Zope Persistence (was: XML-RPC within ZOPE)

2005-12-18 Thread Michael Dunstan
On 12/19/05, Jan-Ole Esleben <[EMAIL PROTECTED]> wrote: > > Little bit tricky to try out as testers need to guess what all the > > missing code is. > > Any standard persistent ZOPE product wrapped around this will do. > These are the only methods in a ZOPE product that inherits from Item, > Persist

Re: [Zope] Re: Zope Persistence (was: XML-RPC within ZOPE)

2005-12-18 Thread Jan-Ole Esleben
> Little bit tricky to try out as testers need to guess what all the > missing code is. Any standard persistent ZOPE product wrapped around this will do. These are the only methods in a ZOPE product that inherits from Item, Persistent, RoleManager and Implicit. > Also, for this kind of code demon

Re: [Zope] Re: Zope Persistence (was: XML-RPC within ZOPE)

2005-12-18 Thread Michael Dunstan
On 12/19/05, Jan-Ole Esleben <[EMAIL PROTECTED]> wrote: > > > 1. In the example, just setting _p_changed=1 does _not_ lead to a > > > conflict error. With the ineffectual code above it (that never gets > > > executed) it _does_. So there _is_ some implicit magical stuff going > > > on and ZOPE trie

Re: [Zope] Re: Zope Persistence (was: XML-RPC within ZOPE)

2005-12-18 Thread Martijn Pieters
On 12/18/05, Jan-Ole Esleben <[EMAIL PROTECTED]> wrote: > > I strongly doubt it. Zope does not "inspect code". There must be a > > problem in your testing. Note that if self.a is a standard list, the > > self.a.append(1) doesn't have any impact on the persistence mechanism or > > transactions eithe

Re: [Zope] Re: Zope Persistence (was: XML-RPC within ZOPE)

2005-12-18 Thread Jan-Ole Esleben
> > 1. In the example, just setting _p_changed=1 does _not_ lead to a > > conflict error. With the ineffectual code above it (that never gets > > executed) it _does_. So there _is_ some implicit magical stuff going > > on and ZOPE tries to take care that only subobjects change (but > > incompletely

Re: [Zope] Re: Zope Persistence (was: XML-RPC within ZOPE)

2005-12-16 Thread Jan-Ole Esleben
Thanks, I will definitely look into that for my immediate problems. Ole 2005/12/16, Michael Haubenwallner <[EMAIL PROTECTED]>: > Jan-Ole Esleben wrote: > > > Thanks; this is a problem we are well aware of. Our solution is to > > increase the amount of workers, obviously. > > > > However, I'm incr