On 16/05/07, Brandon Black <[EMAIL PROTECTED]> wrote:
On 5/15/07, Johan Lindström <[EMAIL PROTECTED]> 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/

_______________________________________________
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