launchpad-dev team mailing list archive

[Guilherme Salgado <salgado@xxxxxxxxxxxxx>]

On Thu, 2010-08-12 at 08:34 +1200, Robert Collins wrote:
> On Wed, Aug 11, 2010 at 4:27 PM, Michael Hudson
> <michael.hudson@xxxxxxxxxxxxx> wrote:
> > On Wed, 11 Aug 2010 15:02:13 +1200, Robert Collins <robert.collins@xxxxxxxxxxxxx> wrote:
> >
> >> The latter are trickier because we want to get all the related data we
> >> want at once, no more than needed, and no less. If we get more things
> >> go slower, and if we get less we scale poorly as the page gets busier
> >> (e.g. more builds). The pattern I've tried in registry with
> >> _all_members should help considerably, once we get the cache coherency
> >> stuff sorted (which strictly speaking only really affects the test
> >> suite : production clears storm caches between requests, and so caches
> >> on model objects have no lifetime in the actual server).
> >
> > What's the issue here, generally speaking?
> 
> I don't know enough to speak generally.  I can tell you about a
> specific problem.
> 
> > It's possible to arrange for
> > caches to be cleared on many boundaries -- for example, the per-request
> > security policy cache is cleared when the principal changes, which
> > happens during login.  Clearing all @cachedpropertys like this might not
> > scale very well, but otoh there might be something we can do.
> 
> Sure.
> 
> So there are two caches per model object [at a baseline level]
> 
> *) cachedproperty. This is stored in the model object, as
> _attributename_cached attributes.

We used to avoid cachedproperties on model classes as debugging things
when you have a (sometimes unexpected) caching at that layer is not fun,
but we seem to have lots of them now.

I remember that Bjorn used to advocate strongly for us not using them.

-- 
Guilherme Salgado <https://launchpad.net/~salgado>

Attachment: signature.asc
Description: This is a digitally signed message part