Hi,
I'm seeing an issue where I do an insert and upon subsequent requests,
certain children are not returning the newly-inserted data (row), while
others are. Restarting apache fixes this as does waiting for some length of
time.
I'm obviously not running -X nor do I want to (or should I have to
$self->model->log('info', "updating obj:");
$self->model->log_dumper('info', $obj);
eval { $obj->update };
if ($@) {
$self->model->log('info', 'update failed, rolling back');
l->log('info', "updating obj:");
$self->model->log_dumper('info', $obj);
eval { $obj->update };
if ($@) {
$self->model->log('info', 'update failed, rolling back');
foreach my $o (@created)
'relen_date' => '1',
94478 2004-05-17/15:42:28 64.186.244.42 info dave Plugin::Customers 220 'sysid' => '1'
94478 2004-05-17/15:42:28 64.186.244.42 info dave Plugin::Customers 220 }
9
ad should be retrieving 3 hashes)
Is it possible mysql children are feeding httpd children bogus
data?
-Dave
At 02:03 PM 5/18/2004, Perrin Harkins wrote:
[ Please keep the conversation on
the list... ]
On Tue, 2004-05-18 at 16:23, Dave Boodman wrote:
> ok, thanks for the tips on the commit/rollback.
use 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,
Good, you're narrowing it down. If a different child handles the edit and
the view, is it always wrong? You can simulate this when running in -X by
doing the edit, then stopping and restarting the server, then doing the view.
Only a small % of the children consistently get it wrong. The rest,
d 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 Harkin
sorry, I meant Class:DBI's search function.
At 03:08 PM 5/19/2004, Dave Boodman wrote:
breakthrough!
focusing on the view code here:
this doesn't work:
foreach
my $obj (Lib::Systems->search(cid=>$cid)) {
my %e = map { $_ => $obj->$_ } Lib::Systems->column
trieve_all and then filtered out the returns
for the rows I wanted and that didn't work either.
So we know 2 things:
1. Something about using the Class::DBI wrapper functions isn't working
(using pure DBI does)
2. this worked fine before autocommit was turned off
At 03:39 PM 5/19/2004, Perri
And that is the correct primary key for this table?
yes
> The return from the
->search looks like
>
> $VAR1 = \bless( {
>
'sysid' => '158'
>
}, 'Lib::Systems' );
> $VAR1 = \bless( {
>
'sysid' => '1065'
>
}, 'Lib:
BINGO!
If you're ever in San Diego, please contact me. I owe you a beer and dinner.
Dave
At 12:49 AM 5/20/2004, Perrin Harkins wrote:
Dave Boodman wrote:
I don't remember you mentioning that before. If something is not
getting committed to the database, that would cause the process th
12 matches
Mail list logo
