[Dbix-class] Soliciting Design Input for an Object Caching Module

Dave Cardwell list+dbix-class at davecardwell.co.uk
Wed May 16 07:50:32 GMT 2007


On 16/05/07, Brandon Black <blblack at gmail.com> wrote:
> On 5/15/07, Johan Lindström <johanl at darserman.com> wrote:
> > At 00:15 2007-05-16, Brandon Black wrote:
> > >While I think caching at the DBIx::Class level will be useful for some
> > >people, I would think that a lot of users would leave it turned off
> > >for consistency reasons.  Even if you're invalidating the cache
> > >locally on update/delete, that's local to one process.
> >
> > <delurking>
> >
> > Isn't that really up to the design of the cache being used?
> >
>
> Yes.
>
> > If you use two in-memory caches (i.e. in process) for two processes, they
> > will become out-of-sync. So that's the wrong solution. They should use an
> > on-disk cache that is common to the processes.
> >
>
> s/on-disk/in-memory/;
>
> > Same for processes across machines, they shouldn't have two machine local
> > caches, they should use a centralized cache, or memcached, or some other
> > setup that is distributed across the machines.
> >
>
> Yes, that's what I said :)
>
> > But again, isn't that up to the cache itself (and the
> > configuration/deployment of it) to deal with? Not DBIC.
> >
>
> I would assume that different caches have different interfaces and
> behaviors, and we need to either write to a really useful one
> (memcached gets my vote), or we need to first abstract all of the
> useful caching backends into something generic we can use (kinda like
> how Storage abstracts DBI).
>
> -- Brandon
>

I had envisaged writing a driver that was effectively a generic
wrapper for modules that implement the Cache::Cache [1] interface,
with the option for people to inherit from and overwrite the driver's
methods to provide for other cache APIs as required.


[1] http://search.cpan.org/dist/Cache-Cache/lib/Cache/Cache.pm

-- 
Best wishes,
Dave Cardwell.

http://davecardwell.co.uk/perl/



More information about the Dbix-class mailing list