At 03:08 PM 5/19/2004, Dave Boodman wrote:
breakthrough!-- 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
focusing on the view code here:
this doesn't work:
foreach my $obj (Lib::Systems->search(cid=>$cid)) {
my %e = map { $_ => $obj->$_ } Lib::Systems->columns;
push @out, \%e;
}
this does:
my $db = Lib::Systems->dbh;
my $sth = $db->prepare("select * from systems where cid='$cid'");
$sth->execute;
while (my $obj = $sth->fetchrow_hashref) {
my %e = map { $_ => $obj->{$_} } Lib::Systems->columns;
push @out, \%e;
}
...
(Lib::DBI is base classed to Class::DBI)
package Lib::Systems;
use strict;
use base qw( Lib::DBI );
Lib::Systems->table('systems');
Lib::Systems->columns(All => qw( sysid cid machine dir veid os_template hostname gigs start_date cancel_date stop_date sysaudit ));
Lib::Systems->columns(Ordered => qw( machine dir veid hostname gigs os_template start_date cancel_date stop_date sysaudit ));
Lib::Systems->has_many(ip => 'Lib::Ipmap', 'sysid');
Lib::Systems->has_many(customer => 'Lib::Customers', 'cid');
I don't see anything strange in Lib::Systems, and furthermore, the same problem exists when, using another table (and another Lib::xxx to access that table) when performing a similar function - inserts don't always appear but make it to the db. So something is up with the Class::DBI retrieve fxn...???
Dave
At 02:20 PM 5/19/2004, Perrin Harkins wrote:
On Wed, 2004-05-19 at 14:28, 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
> Only a small % of the children consistently get it wrong. The rest,
> including the one that made the insert, get it right. Restarting the server
> always sets all children straight.
That makes it sound like you have a scoping issue in your code which
causes the first set of objects that is edited (or maybe the first set
viewed) to remain in memory and be shown again when they should not be.
> >So the data always gets written to the database, but sometimes doesn't
> >show up when you select it on the view page? I'd suggest focusing on the
> >view page then, until you find the exact place in the code where it starts
> >doing something unexpected. That may not be the source of the problem,
> >but it may tell you what the problem is.
>
> Good point, but the code that generates the view page, is used all over,
> and I never see this problem.
Huh? Didn't you say that the view page is where you see this problem?
The view page may not be the source of the problem, but if you can
identify where something unexpected starts to happen on that page (e.g.
this method call returns a different set of objects than you expected),
that will help you locate the problem code. You have to keep following
things up the chain until you discover the source of the problem.
> >What I meant by that is clearing all of your test data between tries, so
> >that you know you are doing exactly the same test each time and not just
> >seeing left over problems from the last run.
>
> I'm inserting data with an autoincrement so I don't think this is necessary.
If you don't delete the data, you are not doing a fully controlled
test. It may not affect your testing, but it's safer to delete it.
> Any more ideas? From here I'm ready to trash all my code and start over
> with the simplest handler that just does an insert an a retrieve (in
> separate calls).
You could do that. I would probably just keep taking things out rather
than starting from scratch. Being able to reproduce the problem at will
would really help, which is why I was pushing you to experiment more
with -X.
- Perrin
