On Tue, 2004-05-18 at 19:15, Dave Boodman wrote:
> I'm testing by submitting (in a browser) the page/form (the "edit"
> page) that (at this point) just calls the code to do the insert (as
> you can see I've specified the data to insert, ignoring what's in the
> form). I do the same when I run in -X. To reproduce the error, I have
> another browser open that retrieves the items for a given customer
> (the "view" page). Immediately following the "edit" page submit. I
> relaod the "view" page and corresponding to the # of hashes you see in
> the logs I included, that's the # of items I see showing up.
Okay, so when you do this without -X, you have no way of knowing whether
or not you hit the same child process twice or not. With -X on, try
submitting the edit page several times in a row before pulling up the
view page, or submitting the view page several times before pulling up
the edit page, etc. That's the sort of thing that could be happening
when you run without -X. If you vary the input to the edit page at all
during your testing, experiment with that too.
> The code that generates the "view" page and the hashes returned log
> entries is:
>
> sub retrieve {
> my $self = shift;
> my $cid = shift;
> my @out;
> foreach my $obj (Lib::Systems->search(cid=>$cid)) {
> # strip out the Class::DBI bits
> my %e = map { $_ => $obj->$_ } Lib::Systems->columns;
> push @out, \%e;
> }
> $self->model->log('debug', "retrieve($cid) returning ".scalar
> @out." hashes" );
> return [EMAIL PROTECTED];
>
> } # end retrieve
You could try verifying that the SQL is getting the right thing by
checking the database yourself before running the view page. If it
looks the same, then you can eliminate the view page as a possible
source of problems.
> I tried your suggestion of replacing Lib::Systems with:
>
> from DBI.pm:
> <SNIP>
> use base 'Class::DBI';
> <SNIP>
> sub dbh {
> return DBI->connect(DB_DSN, DB_USERNAME,
> DB_PASSWORD,{AutoCommit => 0})
> || die $DBI::errstr;
> } # end dbh()
> <SNIP>
>
> replaced code inside update():
>
> my $db = Lib::Systems->dbh;
> <SNIP>
> eval { $db->do("insert into systems (cid,start_date,machine) values
> ('col00179','2004-05-18','test')") };
>
> and I get the same results.
I don't know enough about your system to interpret that, but taking
things out until the problem goes away is the right approach. Try
hard-coding the input instead of actually reading the form data and see
if that makes a difference. See what else you can take out. And make
sure you are resetting your database between tries.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
