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
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
> 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
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
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
> > 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
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