[Dbix-class] REPOST: memcache / DBIx::Class

[Frank Speiser]

Matt S Trout wrote:
> On Tue, May 29, 2007 at 03:14:16PM -0400, Frank Speiser wrote:
>   
>> Hi Folks,
>>
>> [ APOLOGIES IF I MUFFLED UP YOUR EMAIL CLIENT ]
>>
>> I was wondering if anyone had thoughts on how to best implement memcache 
>> support.
>> Currently, I am looking for a way to pull out the prepared SQL from the 
>> statement handle, and maybe override or subclass DBI's execute method.
>>
>> What I'm trying to do is make sure I don't have to wrap every* call to 
>> cache...
>>
>> I would think we might try do it at resultset 
>> (http://search.cpan.org/dist/DBIx-Class/lib/DBIx/Class/ResultSet.pm),
>> but Matt Trout was saying in this thread:
>>
>> http://www.mail-archive.com/dbix-class@lists.rawmode.org/msg03182.html
>>
>> ... to do it at the storage layer. I don't know if that is the best 
>> solution for us, but if anyone has managed to get memcache built in so 
>> that you don't have to wrap every call the the DB, I'd appreciate 
>> comments on how you got it to work.
>>     
>
> 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 $source
> it's passed, if we moved find() to using select_single ... but I think I like
> the source doing it so it can re-cache by any other identities when it happens).
>
> 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 resultset
> level and should probably be implemented via intercepting the get/set_cache
> methods.
>
> 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 :/

I could see Oleg's solution (#1) working too, if we were able to make 
get/set_cache to do the right thing.

-Frank