[Dbix-class] REPOST: memcache / DBIx::Class
Matt S Trout
dbix-class at trout.me.uk
Tue May 29 21:34:44 GMT 2007
On Tue, May 29, 2007 at 04:12:59PM -0400, Frank Speiser wrote:
> >I'm starting to think Oleg and I were possibly -both- right :)
> >I think we've got more than one use case here -
> >(1) caching of specific queries
> >(2) general resultset query caching
> >(3) specific find-by-identity (PK/UK/etc.) caching
> >I'm fairly sure (3) probably wants to happen at the resultsource level
> >so it's shared across all resultsets (or via storage dealing with the
> >it's passed, if we moved find() to using select_single ... but I think I
> >the source doing it so it can re-cache by any other identities when it
> >I -think- (2) is probably best at storage since it's "any and all queries".
> >And (1), which is the case Oleg originally had, is correctly done at
> >level and should probably be implemented via intercepting the get/set_cache
> >Which one (or more) of these are you looking at?
> >What do people reckon?
> In just some simple tests, we've been looking at (#2), there, for what
> it's worth. It would seem that making ->resultset behave that way would
> do the best at keeping it out of the way and making it DWIW.
> However, my opinion probably doesn't weight very much here, since I'm
> the guy that asked the original question :/
Why are you trying to cache -all- queries?
Mightn't it not be more efficient overall to -not- cache generic selects but
to always select only the PK and then cache the individual objects per PK?
You're going to need to do some serious thinking about your DB load and
what sorts of queries are (un)likely before you can tell what's likely to
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director Want a managed development or deployment platform?
Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote
More information about the Dbix-class