50016 2004-05-18/15:58:10 64.186.244.42 debug dave Plugin::Systems 33 retrieve(col00179) returning 5 hashes
50014 2004-05-18/15:58:10 64.186.244.42 debug dave Plugin::Systems 33 retrieve(col00179) returning 6 hashes
50413 2004-05-18/15:58:10 64.186.244.42 debug dave Plugin::Systems 33 retrieve(col00179) returning 6 hashes
50527 2004-05-18/15:58:10 64.186.244.42 debug dave Plugin::Systems 33 retrieve(col00179) returning 5 hashes
50017 2004-05-18/15:58:11 64.186.244.42 debug dave Plugin::Systems 33 retrieve(col00179) returning 6 hashes
I've never seen a case where the same child that does the update/insert doesn't return the new data on a subsequent view reload.
I have tried varying the input and that has not changed the results. In the most recent test's I am ignoring the form data (hard-coding the data in the insert).
In regular mode (not -X), I just did 2 edits (inserts) confirmed that the rows are in the db using the mysql client, and the view page reloads are showing the same thing: some show the new inserts some don't.
Because I always see the data in the database with the mysql client, I figured it wasn't an issue with the view page per-se, more a problem with the insert (new data) not being seen by the child.
How should I be resetting the db (mysql)?
-Dave
At 04:35 PM 5/18/2004, Perrin Harkins wrote:
On Tue, 2004-05-18 at 19:15, Dave Boodman wrote:-- 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
> 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
