[Dbix-class] memcache / pulling out SQL from DBIx::Class

[Brandon Black]

On 5/29/07, Frank Speiser <frank at takkle.com> wrote:
> Hi Folks,
>
> I was wondering if anyone had thoughts on how to best implement memcache
> support.
> Currently, I am looking for a way to pull out the prepared SQL from the
> statement handle, and maybe override or subclass DBI's execute method.
>
> What I'm trying to do is make sure I don't have to wrap every* call to
> cache...
>
> I would think we might try do it at resultset
> (http://search.cpan.org/dist/DBIx-Class/lib/DBIx/Class/ResultSet.pm),
> but Matt Trout was saying in this thread:
>
> http://www.mail-archive.com/dbix-class@lists.rawmode.org/msg03182.html
>
> ... to do it at the storage layer. I don't know if that is the best
> solution for us, but if anyone has managed to get memcache built in so
> that you don't have to wrap every call the the DB, I'd appreciate
> comments on how you got it to work.
>

If you search the archives, there have been a few other relevant
conversations lately wrt to integrating memcached (and other caching
strategies).

I don't think memcached can be generically interfaced at the storage
layer very easily.  In theory, you could use the final prepped
statement + arguments as a key for the results, but that doesn't leave
one any way to invalidate/update the cache on insert/update/delete in
any sort of sane manner I don't think.

The better strategy is probably to integrate it at the resultset layer
to cache objects based on PKs, as we can probably invalidate it
properly on insert/update/delete there, something like Oleg's
approach.

We probably want to abstract caching in general, in much the same way
that Storage is abstracted between vendors, so that you can choose
$caching_module and the interface between resultsets and caching stays
the same.  We probably want to expose the ability to cache/invalidate
arbitrary keys at the resultset level using the abstraction too, so
that people can add custom resultset methods that fetch/cache more
complex queries that can't be automatically keyed in the cache, and
invalidate them with other calls at the right places.

-- Brandon