Grokbase
Topics Posts Groups | in
x
[ help ]

Paul Makepeace (p...@paulm.com)

Profile | Posts (31)

User Information

Display Name:Paul Makepeace
Partial Email Address:p...@paulm.com
Posts:
31 total
1 in Catalyst Framework Development
11 in Catalyst Framework
10 in DBIx::Class
9 in dbix-class@lists.scsys.co.uk

5 Most Recent

All Posts
1) Paul Makepeace [Catalyst] Speed up access to your favorite JavaScript frameworks
| +1 vote
This might help some here who use AJAX....
catalyst@lists.scsys.co.uk
[ Profile | Reply to group ] [ Flat  Thread  Threaded ]
This might help some here who use AJAX.

/*
http://googleajaxsearchapi.blogspot.com/2008/05/speed-up-access-to-your-favorite.html

We have worked with a subset of the most popular JavaScript frameworks
to host their work on the Google infrastructure. The AJAX Libraries
API then becomes a content distribution network and loading
architecture for these libraries.

We realize that there are a huge number of useful libraries out there,
but we wanted to start small with the program, which has us starting
with:

   * jQuery
   * prototype
   * script.aculo.us
   * MooTools
   * dojo

*/

They're automatically versioned too, so if you request version "1" of
jQuery you get 1.6.4 or whatever it is right now; "1.3" you get latest
in 1.3 branch etc.

Paul
2) Paul Makepeace [Dbix-class] Re: $row->copy causing exit from controller(!)
| +1 vote
ARGH! Would you pretty please consider applying this year old patch to an even older feature that...
catalyst@lists.scsys.co.ukdbix-class@lists.scsys.co.uk
[ Profile | Reply to groups ] [ Flat  Thread  Threaded ]
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@paulm.com> wrote:
>
> On Thu, May 8, 2008 at 11:52 AM, Ash Berlin <ash_cpan@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@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
>  >
>
3) Paul Makepeace [Dbix-class] Re: $row->copy causing exit from controller(!)
| +1 vote
It was still happening with 0.08010 but the StackTrace upgrade appears to be now catching it....
catalyst@lists.scsys.co.ukdbix-class@lists.scsys.co.uk
[ Profile | Reply to groups ] [ Flat  Thread  Threaded ]
On Thu, May 8, 2008 at 11:52 AM, Ash Berlin <ash_cpan@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@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
>
4) Paul Makepeace [Dbix-class] Re: $row->copy causing exit from controller(!)
| +1 vote
I had the stroke of intuition to wrap the call to copy() in an "eval {}; warn @$ if $@;" and saw...
catalyst@lists.scsys.co.ukdbix-class@lists.scsys.co.uk
[ Profile | Reply to groups ] [ Flat  Thread  Threaded ]
On Thu, May 1, 2008 at 11:31 AM, Paul Makepeace <paulm@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.)

There's a series of BEGIN/COMMIT/ROLLBACK lines coming out of
somewhere in the FastCGI screen too, FWIW.

http://search.cpan.org/~ash/DBIx-Class-0.08010/lib/DBIx/Class/Row.pm#copy
doesn't give any hint that multiple rows would be inserted.

Does this sound plausible?

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.

P


>
>  **
>
> I realize there's scads of debug I could provide but wanted to check
> first this wasn't something someone had run into before. If not, what
>  kind of debug can I provide?
>
>  DBIC $VERSION = '0.08009';
>  Catalyst 5.7012
>
>  Paul
>
5) Paul Makepeace [Catalyst] Re: $row->copy causing exit from controller(!)
| +1 vote
I'm assuming I can just click in the test server and readily re-exhibit the bug myself without...
catalyst@lists.scsys.co.uk
[ Profile | Reply to group ] [ Flat  Thread  Threaded ]
On Fri, May 2, 2008 at 2:22 PM, Kieren Diment <diment@gmail.com> wrote:
>
>  On 2 May 2008, at 23:04, Paul Makepeace wrote:
>
>
> > On Thu, May 1, 2008 at 4:21 PM, Aristotle Pagaltzis <pagaltzis@gmx.de>
> wrote:
> >
> > > Hi Paul,
> > >
> > > * Paul Makepeace <paulm@paulm.com> [2008-05-01 17:00]:
> > >
> > >
> > > > How does one use perl -d in the context of a FastCGI instance?
> > > > Any other debugging tips?
> > > >
> > >
> > > does your problem happen only with the FastCGI engine or can you
> > >  reproduce it with others?
> > >
> >
> > You mean like running the foo_server.pl on port 3000? I haven't done
> > that yet, partly as my app is a Cat/PHP hybrid so I'm having to modify
> > my login system to work without PHP.
> >
> > That aside, and so I'm understanding what's being proposed here:
> > modifying the foo_server.pl to use perl -d and breakpointing the
> > controller, then stepping through based on a hit?
> >
> >
>
> Yeah, that works, but if you're having a problem with web server
> deployment, you're probably better off writing test cases and dumping data:
>
> CATALYST_SERVER=http://somewhere.com/myapp prove -l t
>
> then you know if you're getting identical behaviour with the test server
> and your 'real' server which is important information, especially as the
> test server is much easier to debug.

I'm assuming I can just click in the test server and readily
re-exhibit the bug myself without writing test cases (although I don't
doubt their worth in the general case).

The question I'm asking is how to debug the system given the test
server & FastCGI are both exhibiting this weird failure mode.

P


>
>
>
>
>
>  _______________________________________________
> List: [email protected: Cat...@lists.scsys.co.uk]
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>

spacer
Profile | Posts (31)
Home > People > Paul Makepeace