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

On 5/29/07, Matt S Trout <[EMAIL PROTECTED]> 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




_______________________________________________
List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
Wiki: http://dbix-class.shadowcatsystems.co.uk/
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
Searchable Archive: http://www.mail-archive.com/[email protected]/

Reply via email to