On 8 May 2008, at 10:42, Paul Makepeace wrote:
On Thu, May 1, 2008 at 11:31 AM, Paul Makepeace <[EMAIL PROTECTED]>
wrote:
I'm seeing something exceedingly odd: copying data causing a
premature
return from the controller, like a detach(),
foreach my $table (@chart_related_tables) {
my $rs = $ds->resultset($table);
warn "copying $table for ", $new_chart->uid;
for my $row ($rs->search({web_chart_spec_uid => $chart-
>uid})) {
warn "..row ", $row->web_chart_spec_uid, $row;
$row->copy({web_chart_spec_uid => $new_chart->uid}); #
XXX
}
#$_->copy({web_chart_spec_uid => $new_chart->uid})
#for $rs->search({web_chart_spec_uid => $chart->uid});
die "cloned", $new_chart->uid;
}
There's no further execution past the line marked XXX: the template
is
rendered from that point on. The die is never called.
I have a feeling it's something to do with has_many
Chart:
__PACKAGE__->has_many(chartview_company =>
'IDL::Schema::ChartCompany'
=> 'web_chart_spec_uid', {cascade_delete => 0});
If I exclude from @chart_related_tables ChartCompany it works.
I had the stroke of intuition to wrap the call to copy() in an "eval
{}; warn @$ if $@;" and saw what is going on. It seems like the copy()
is not just copying the row but other rows as well, which is in turn
causing duplicate key errors, in particular the rels mentioned above
that have has_many. The controller at least completes now. (Why an
error like this would bypass the exception handler is a mystery and
presumably a bug.)
This is what Jon Rockway and myself were saying. Somewhere in your
application stack you have an die handler/eval block that is clearing
[EMAIL PROTECTED] If you dont have Catalyst::Plugin::StackTrace installed (or have
an old version) I'm not sure what could be causing it.
Try upgrading to latest ver of DBIx::Class - 0.08010 - I think that I
might have fixed a possible cause of losing an exception between 09
and 10 in Row->insert, which might be used by copy. Worth a go.
Sorry I haven't got more debug, I'm squeezing this into occasional
spare minutes here and there. If there's something specific I can try
or provide, let me know. Unfortunately getting the fastcgi working
with perl -d isn't likely any time soon. I don't think it's there in
any case; it feels more DBIx::Class related.
This same error should also happen under the myapp_server.pl, which
makes it some what easier to run under perl -d if upgrading doesn't
make the exception appear properly.
_______________________________________________
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/[EMAIL PROTECTED]
