Re: [Dbix-class] Caching a resultset?
On Tue, Jan 15, 2013 at 05:18:06AM +1100, Peter Rabbitson wrote: On Mon, Jan 14, 2013 at 11:07:34AM -0500, Jesse Sheidlower wrote: So apart from the mystery around the nonsensical exception - does this help? local $DBIx::Class::ResultSourceHandle::thaw_schema = $c-model(...)-schema; Yes! Putting that before the unless seems to make everything work correctly Will be testing further this afternoon. Thanks! Please let me know if wider testing is succesful. In one sense, wider testing was indeed successful. The RS was cached properly, it worked in several different environments, etc. However, it didn't work in one particularly crucial way, which in retrospect I'm surprised I didn't think about: the resultset may have been cached, but once I get it back, it's still just a resultset, so when I use it again in the template, it hits the database again. Every time. This is exactly what I wanted to avoid by this whole escapade. ___ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk
Re: [Dbix-class] Caching a resultset?
On Tue, Jan 15, 2013 at 02:15:02PM +, David Cantrell wrote: On Sun, Jan 13, 2013 at 11:35:06PM -0500, Jesse Sheidlower wrote: I have a Catalyst app that very frequently (pretty much every request) requires several DBIC resultsets that return a small number of values, that very rarely change. I'm trying to cache this, so I can update the cache when the values change and not have to hit my DB a half-dozen times on every request for data that is effectively static. To solve this problem at the BBC in the guts of iPlayer, we used memcache. We *didn't* bother updating the cache if the DB contents changed though, as we didn't mind the user's view being a few minutes out of date. While it wouldn't matter much if things were a little out of date, my site is relatively low traffic, so caching something for a few minutes wouldn't make much difference. So I need to cache it long-term, and I do need to update on a change. I've spent quite a bit of time thinking about how to solve this in the general case, and not come up with anything that works yet - not even anything that works in theory and goes arse-over-tit in practice. Can you at least reduce it to one query with a left right in out shake it all about join? Not really. The problem is that I have a number of separate, unrelated tables, each having category-like data (category, status, region, other-status, etc.), and each being used in different ways, so I have to get each table separately. ___ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk
Re: [Dbix-class] Caching a resultset?
On Tue, Jan 15, 2013 at 10:09:19AM -0500, Jesse Sheidlower wrote: On Tue, Jan 15, 2013 at 05:18:06AM +1100, Peter Rabbitson wrote: On Mon, Jan 14, 2013 at 11:07:34AM -0500, Jesse Sheidlower wrote: So apart from the mystery around the nonsensical exception - does this help? local $DBIx::Class::ResultSourceHandle::thaw_schema = $c-model(...)-schema; Yes! Putting that before the unless seems to make everything work correctly Will be testing further this afternoon. Thanks! Please let me know if wider testing is succesful. In one sense, wider testing was indeed successful. The RS was cached properly, it worked in several different environments, etc. However, it didn't work in one particularly crucial way, which in retrospect I'm surprised I didn't think about: the resultset may have been cached, but once I get it back, it's still just a resultset, so when I use it again in the template, it hits the database again. Every time. This is exactly what I wanted to avoid by this whole escapade. You need to combine the above with [1] and/or [2]. [1] https://metacpan.org/module/DBIx::Class::ResultSet#cache [2] https://metacpan.org/module/DBIx::Class::ResultSet#set_cache Cheers ___ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk
Re: [Dbix-class] Caching a resultset?
On Tue, Jan 15, 2013 at 05:12:12PM +0100, Alexander Hartmaier wrote: On 2013-01-15 16:51, Peter Rabbitson wrote: On Tue, Jan 15, 2013 at 10:09:19AM -0500, Jesse Sheidlower wrote: On Tue, Jan 15, 2013 at 05:18:06AM +1100, Peter Rabbitson wrote: On Mon, Jan 14, 2013 at 11:07:34AM -0500, Jesse Sheidlower wrote: So apart from the mystery around the nonsensical exception - does this help? local $DBIx::Class::ResultSourceHandle::thaw_schema = $c-model(...)-schema; Yes! Putting that before the unless seems to make everything work correctly Will be testing further this afternoon. Thanks! Please let me know if wider testing is succesful. In one sense, wider testing was indeed successful. The RS was cached properly, it worked in several different environments, etc. However, it didn't work in one particularly crucial way, which in retrospect I'm surprised I didn't think about: the resultset may have been cached, but once I get it back, it's still just a resultset, so when I use it again in the template, it hits the database again. Every time. This is exactly what I wanted to avoid by this whole escapade. You need to combine the above with [1] and/or [2]. [1] https://metacpan.org/module/DBIx::Class::ResultSet#cache [2] https://metacpan.org/module/DBIx::Class::ResultSet#set_cache Cheers You mean don't prefetch the relationships and populate it's cache after fetching all results? Um... prefetch does not touch the cache of the *main* rs. I am not sure what you mean above - explain. Cheers ___ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk
