I've already done this and it works fine for general things.
Caching at storage layer is much worse:
Benchmark (wallclock time). 1000 times.
->single (w/o): 1.8s
(cache at storage): 1s
(cache at resultset): 0.5s
->search (not complex) (w/o): 5sec
(cache at storage): 1.7sec
(cache at resultset): 0.7s
Resultset's methods spend much time creating objects from storage results.
This is a lot of useless work if you want to cache results.
I already use it in production and everything's fine. (resultsetcolumn and
iterators are not cached).
2007/5/8, Matt S Trout <[EMAIL PROTECTED]>:
On Thu, Apr 26, 2007 at 10:12:41PM +0400, Oleg Pronin wrote:
> Hello!
>
> I want to create custom resultset class that will allow caching (in
> memcached) functionality.
Don't.
Do it at the storage layer.
--
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
http://www.shadowcatsystems.co.uk/
_______________________________________________
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]/
_______________________________________________
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]/
