Re: [Catalyst] DBIC v Cache: What are catalyst best practices for caching DBIC results (with relationships included)
'Cause I'm outta the loop. That looks quite nice. The doc is a bit terse (though that might really be all there is to it). Can you clear just a part of the cache? It's okay if not but I'd like to be able to clear one document or result_set out when it's updated without messing with others that haven't changed. I suppose you might be able to do that by refetching it? Is there any code visible out there -- especially Cat code -- that is using it to take a look at? Thanks, Matt! -Ashley On Nov 14, 2007, at 4:43 PM, Matt S Trout wrote: On Wed, Nov 14, 2007 at 12:08:29PM -0800, Ashley Pond V wrote: I'm having trouble getting Plugin::Cache to handle DBIC objects correctly. Past instruction, and recent refresher, from MST shows that you have to reset/revive the result source and this works for a single object but blows up for prefetch. Why not just use DBIx::Class::Cursor::Cached ? -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/ catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/ servers/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/ [EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] DBIC v Cache: What are catalyst best practices for caching DBIC results (with relationships included)
On Wed, Nov 14, 2007 at 12:08:29PM -0800, Ashley Pond V wrote: > I'm having trouble getting Plugin::Cache to handle DBIC objects > correctly. Past instruction, and recent refresher, from MST shows > that you have to reset/revive the result source and this works for a > single object but blows up for prefetch. Why not just use DBIx::Class::Cursor::Cached ? -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] DBIC v Cache: What are catalyst best practices for caching DBIC results (with relationships included)
I'm having trouble getting Plugin::Cache to handle DBIC objects
correctly. Past instruction, and recent refresher, from MST shows
that you have to reset/revive the result source and this works for a
single object but blows up for prefetch.
In this code
my $article = $c->cache->get($id);
if ( $article )
{
$article->result_source($c->model("DB")->source
("article"));
}
else
{
$article = $c->model("DB::article")->find($id)
or die "RC_404: no such article";
$c->cache->set($id, $article);
}
No problem. But I really want to save the related object trips to the
DB too. So, since articles may have comments I want to prefetch them
as they will be used beneath an article. But then they are missing
their result_source and resetting it does not seem to work(?). The
following code produces an error when reloaded after first being cached.
my $article = $c->cache->get($id);
if ( $article )
{
$article->result_source($c->model("DB")->source
("article"));
$_->result_source($c->model("DB")->source("comment"))
for $article->comments();
}
else
{
$article = $c->model("DB::article")
->find($id,
{ prefetch => [qw/comments/] }
)
or die "RC_404: no such article";
$c->cache->set($id, $article);
}
Caught exception in MyApp::Controller::Article->article "Can't call
method
+ "source" on an undefined value at
+ /Library/Perl/5.8.6/DBIx/Class/ResultSourceHandle.pm line
+ 62."
What am I doing wrong? Can this be handled at all (resetting
result_sources gets ugly fast when you bring in the other involved
objects like user and document lineage)? What is the best practice
regarding caching DBIC results in Catalyst?
Thanks!
-Ashley
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Ubuntu / Catalyst
Matt S Trout wrote: That's because I was bitching about later Ubuntus, not Dead Rat. Dead Rat == CentOS 5? I simply don't consider RH distros a deployment platform you'd choose unless mandated to use them, and prefer to build my own perl if I have to. CentOS 5's vendor perl will show a 2* performance hit due to their inability to maintain a perl package. Just Don't. OK, thanks - I'll stick with 6.06 for now. -- Richard Jones ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Ubuntu / Catalyst
On Wed, Nov 14, 2007 at 11:43:33AM +1030, Jon Schutz wrote: > Personally I would not consider Ubuntu suitable as a production server > platform as it is too close to the bleading edge. Because 6.06 is the long-term supported release it's been rather more conservative. As I've already said, I don't consider the non-LTS releases suitable either, but we deployed 6.06 when Debian stable was still 3.0 and -way- too behind the times for our tastes. I suspect our next revision of our platform will be to Debian 4 if nothing better comes along in the mean time. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] The Catalyst book?
When will the Catalyst book be published? I don't see it on the Packt publishing list Gerda Shank ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Ubuntu / Catalyst
> On Tue, Nov 13, 2007 at 11:16:54AM +, Richard Jones wrote: > > Peter Edwards wrote: > > >Centos 5 == Red Hat Enterprise Linux 5. > > >For production quality, you can expect it to be pretty stable and I have > > >corporate customers running it successfully. It's one of our development > > >platforms. > > >However, note mst's comments about the broken Perl on it. I found that > > >quite > > >shocking considering it's supposed to be a premier Linux hosting platform. > > >As usual, compiling your own perl and Apache and providing your own > > >PERL5LIB > > >dir per live application area is a sane way of going about delivering > > >standardised live applications you can roll out and support. > > > > > > > Possibly a bit OT now, but as I'm about to set up another production > > server and was going to use CentOS 5, I'm a bit concerned. Matt > > mentioned fstab and init, but not as far as I can see Perl - in what way > > is Perl broken on CentOS 5? > > That's because I was bitching about later Ubuntus, not Dead Rat. > > I simply don't consider RH distros a deployment platform you'd choose unless > mandated to use them, and prefer to build my own perl if I have to. > > CentOS 5's vendor perl will show a 2* performance hit due to their inability > to maintain a perl package. > > Just Don't. While I mostly agree with Matt's take on unix/linux issues -- I will give my support to Cent/RH here. It is true, they have had some missteps with perl in the past. Those tend get resolved fairly quickly. The perl speed issue listed above is fixed in current patches. RH/Cent has some very undeniable advantages over ubuntu/suse/flavor of the day. Some advantages likely to make a difference in corporations are tight partnerships with dell and other server vendors (read tightly coupled hardware support and updates), tight relationships with commercial software vendors (pick 5 software packages that run on linux from different vendors chances are the common supported platform will be RH and therefore CentOS). It is also not uncommon to build your own kit for webserver/perl/mysql etc for production servers no matter what distro you choose -- and run that in parallel to the distro's build. It makes sense to control the bits that run your applications. In general, when it comes to linux distros, my belief is that issues you have with distros can generally be pinpointed down to the administrator (myself included). I have used all of the big 6 Linux distros and found things I like and dislike about all of them. They are all acceptable for hosting perl web apps. -Wade ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
