launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Fri, Aug 13, 2010 at 1:19 AM, Bjorn Tillenius <bjorn@xxxxxxxxxxxxx> wrote:
> On Thu, Aug 12, 2010 at 09:19:35AM -0300, Guilherme Salgado wrote:
>> 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.
>
> FWIW, the reason I usually advocate against cachedproperty on model
> classes is basically what Salgado said. Especially since usually you can
> solve the problem in some other way, which makes it more clear that
> caching (that isn't being automatically invalidated when needed) is
> used.

Yeah. FTR I'm not happy about advocating for using lots of caching in
the model code : however its available -now- whereas my handwavy
might-be-nice stuff isn't available and noone has the bandwidth to
work on it AFAICT. We can mitigate many risks around caching by adding
invalidation, and as most requests are reads we're in pretty good
shape risk wise.

> What I don't like about cachedproperty is that it easily becomes a tool
> that simply replaces @property. People just just it, just in case it's
> needed, without any thought about what the implications are.

Ugh; well I can see that being a risk too. OTOH we have no way to
represent many of our derived data except via caching (cachedproperty
or otherwise).

> That said, I'm not against that kind of caching on the model object.
> Most of our request are read transactions, and for such transactions
> it's safe to use. It might be intresting experimenting with
> automatically caching properties in read transactions.

That would be really very interesting too. One possible failure mode
is that writes (which are already bottlenecking on master) would
perform much worse than reads.

-Rob