[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dbi-users
Subject:    DBI & memcached (was: Google SoC: Fame and Fortune ($4500) await
From:       Tim Bunce <Tim.Bunce () pobox ! com>
Date:       2008-03-19 10:59:12
Message-ID: 20080319105912.GA863 () timac ! local
[Download RAW message or body]

On Wed, Mar 19, 2008 at 03:12:30AM -0000, Greg Sabino Mullane wrote:
> 
> > I'm thinking about creating a merge between DBI and memcached. So cache
> > would be handled automaticly and integration would be seamless. This idea
> > occured to me a few times, since i was writing web app's which took
> > advantege of memcached. I was always getting tired of manual cache
> > management, and if you are using some ORM, it even harder to manage cache
> > propely. With plain SQL you could do something like $cache->set($key ,
> > $value), and then $cache->get($key), where $key would be your SQL statement,
> > which work fine in most cases.
> 
> I'm actually writing something very similar at the moment, and it's a lot
> tricker than that, as you have to account for placeholders, as well as writing
> a way to do cache invalidation. I'd be happy to have you take my work (which
> is very Postgres-specific) and expand it into a generic DBI caching mechanism,
> of which memcached would just be one method to use.

I'll also throw in a mention of DBD::Gofer, which now supports caching
using any class that implements get($key) and set($key, $value) methods.

In fact you can enable basic caching for idempotent queries in *any*
application, with no code changes, just by setting an env var:

    DBI_AUTOPROXY='dbi:Gofer:transport=null;cache=1'

Tim.
[prev in list] [next in list] [prev in thread] [next in thread]