On Thu, 18 Apr 2002 17:35:17 + (UTC), Florent Guillaume
<[EMAIL PROTECTED]> wrote:
>I'll investigate clearing the _v_ caches at the end of the transaction,
>using the REQUEST._hold hack mentionned earlier.
Below is the class I use for this. Just call
attribute_cleaner(self,'_v_my_attribute')
Toby Dickenson <[EMAIL PROTECTED]> wrote:
> >This reminds me of a question I had: given that (from what I understand)
> >_v_ attributes only live in the object cache of a given Zope,
>
> True, and more accurate that I think you expected
>
> The issue is that one Zope has more than one ZODB
> Ive never looked at LDAPUserFolder so this may be irrelevant, but is
> it possible for LDAPUserFolder to validate that the cached _v_
> information is still fresh? If that validation is quicker than
> fetching a new copy then this is still an overall win.
yes it does have a very rough way of va
On Thu, 18 Apr 2002 16:23:15 + (UTC), Florent Guillaume
<[EMAIL PROTECTED]> wrote:
>This reminds me of a question I had: given that (from what I understand)
>_v_ attributes only live in the object cache of a given Zope,
True, and more accurate that I think you expected
The issue is that
Florent Guillaume wrote:
>
> Or am I misunderstanding something ? My question really relates to any
> use of _v_ as a cache that can survive on publisher transaction, really.
> Should _v_ never be used like that ?
There's a case to be made for attributes that not persisted (like _v_
attributes)
