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

[Paul Makepeace]

ARGH!

Would you pretty please consider applying this year old patch to an
even older feature that doesn't appear anywhere at all in the docs?

http://osdir.com/ml/lang.perl.modules.dbix-class/2007-03/msg00106.html

Paul

On Thu, May 8, 2008 at 12:20 PM, Paul Makepeace <paulm at paulm.com> wrote:
>
> 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
>  >
>