launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Fri, Aug 13, 2010 at 6:20 PM, Jeroen Vermeulen <jtv@xxxxxxxxxxxxx> wrote:
> On 2010-08-13 05:02, Robert Collins wrote:
>
>> 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).
>
> I see another risk as well: is __storm_invalidated__ good enough?  If a
> @cachedproperty involves data that's one or more joins away, who says that
> __storm_invalidated__ will ever be invoked before you re-use stale data?

Nothing does: cache invalidation is hard :). OTOH I wouldn't expect
stuff many joins away to be cached like that: I'd expect an object
graph in python to be assembled, which would be cheap to traverse
(because its cached).

> A safer approach that I've seen, though less aggressive and less convenient,
> is to adapt-and-delegate.  It feels a lot like caching in browser code.  Say
> Foo implements IFoo.  You load up a Foo from the database, but adapt it to
> ICachingFoo.  That gives you an object that delegates IFoo to the real Foo,
> but adds all sorts of caching.  The model object stays cached as
> aggressively as the ORM can manage, but the object's caches are gone when
> you finish with the request.

So, this is very much like what I'm handwaving about: separation of
'in-db' and 'in python' content-and-code.

However, one of the problems with doing it with a decorator is this:
class Model:
    @property
    def foo(self):
        <derive stuff>

    def check_something(self):
        if self.foo:
            print "bar"


class CachingModel:
    @cachedproperty
    def foo(self):
        return self.delegate.foo

    def check_something(self):
        return self.delegate.check_something()


Or in english: the uncached object cannot have *any* self-referencing
functions or attributes, or they won't be cached and we won't achieve
the goal.

Of course, sufficiently advanced delgate pokery can make it work, but
at that point I think that its actually more complex and fragile than
the simple caching I'm encouraging for now.

Long term, I think we want
DBObject-with-only-direct-db-info
ModelObject-owns-a-DBObject-and-has-functions-that-we-use

Or something :)

-Rob