[Dbix-class] Re: $row->copy causing exit from controller(!)

[Paul Makepeace]

On Thu, May 8, 2008 at 11:52 AM, Ash Berlin <ash_cpan at firemirror.com> wrote:
>
>
>  On 8 May 2008, at 10:42, Paul Makepeace wrote:
>
>
> > On Thu, May 1, 2008 at 11:31 AM, Paul Makepeace <paulm at paulm.com> 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 $@. If
> you dont have Catalyst::Plugin::StackTrace installed (or have an old
> version) I'm not sure what could be causing it.

It was still happening with 0.08010 but the StackTrace upgrade appears
to be now catching it.

Here's the stacktrace on a single copy,

DBIx::Class::Row 546 /usr/local/share/perl/5.8.8/DBIx/Class/Row.pm


 542: bless $new, ref $self;
 543:
 544: $new->result_source($self->result_source);
 545: $new->set_inflated_columns($changes);
 546: $new->insert;
 547:
 548: # Its possible we'll have 2 relations to the same Source. We need to make
 549: # sure we don't try to insert the same row twice esle we'll violate unique
 550: # constraints


 IDL::Web::Controller::Chart 235
/home/paulm/idl/trunk/IDL-Web/lib/IDL/Web/Controller/Chart.pm


 231: foreach my $table (@chart_related_tables) {
 232: my $rs = $ds->resultset($table);
 233: # TODO: figure out why this fails and needs an eval
 234: $_->copy({web_chart_spec_uid => $new_chart->uid}), last
 235: for $rs->search({web_chart_spec_uid => $chart->uid});
 236: last;
 237: }
 238: $done = "cloned";
 239: } else {



Those comments on lines 548-550 or Row.pm certainly sound in the same realm!

So can you confirm that a copy() does more than just copy a single
row? That's not documented, AFAICS, if so.

The FastCGI screen shows,

BEGIN WORK
COMMIT
BEGIN WORK
COMMIT
BEGIN WORK
COMMIT
BEGIN WORK
COMMIT
BEGIN WORK
COMMIT
BEGIN WORK
COMMIT
BEGIN WORK
COMMIT
BEGIN WORK
COMMIT
BEGIN WORK
COMMIT
BEGIN WORK
COMMIT
BEGIN WORK
COMMIT
BEGIN WORK
ROLLBACK

during that copy.

P

>  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/dbix-class@lists.rawmode.org
>