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
