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
_______________________________________________
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]/
