[Dbix-class] REPOST: memcache / DBIx::Class

[Steve Atkins]

On May 29, 2007, at 2:06 PM, Brandon Black wrote:

> On 5/29/07, Matt S Trout <dbix-class at trout.me.uk> wrote:
>>
>> I'm starting to think Oleg and I were possibly -both- right :)
>>
>> I think we've got more than one use case here -
>>
>> (1) caching of specific queries
>>
>> (2) general resultset query caching
>>
>> (3) specific find-by-identity (PK/UK/etc.) caching
>>
>> I'm fairly sure (3) probably wants to happen at the resultsource  
>> level
>> so it's shared across all resultsets (or via storage dealing with  
>> the $source
>> it's passed, if we moved find() to using select_single ... but I  
>> think I like
>> the source doing it so it can re-cache by any other identities  
>> when it happens).
>>
>
> I think a lot of the ideas/posts on this subject are ignoring cache
> invalidation.  If we cache a result or the realization of a resultset,
> it would be highly inconsistent of us to continue serving stale cached
> data after someone issued a DBIC statement that would have altered
> that information.
>
> Proper cache invalidation is the real thorny thing that makes all of
> the generic approaches difficult to impossible.  (3) I think is the
> lowest-hanging fruit.

When I use memcache I have the database invalidate the
cache when the underlying data changes. That catches
any potentially invalidating change whether it comes from
the webapp, a backend tool, the command line, a trigger
or anything else.

Works very nicely for simple selects, but gets a bit hairier
the more complex the queries get.

(pgmemcache does that nicely for postgresql, I'd guess that
implementing it for any other reasonably built database wouldn't
be hard.)

Even if there were to be full support in DBIC for invalidating
the cache it would be really nice to be able to disable it completely
when the database itself is setup to manage invalidation.

Cheers,
   Steve