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 that did
the in
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:
PK wasn't the problem. If you don't define it, it uses the first col. Even
explicitly defined it didn't work.
The return from the ->search looks like
$VAR1 = \bless( {
'sysid' => '158'
}, 'Lib::Systems' );
$VAR1 = \bless( {
'sysid' => '10
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 that did
the insert to see it, and none of the others. You also should not be
able to see it when connecting to the database from a query tool if it
On Wed, 2004-05-19 at 18:53, Dave Boodman wrote:
> PK wasn't the problem. If you don't define it, it uses the first col.
And that is the correct primary key for this table?
> The return from the ->search looks like
>
> $VAR1 = \bless( {
> 'sysid' => '158'
>
On Wed, 2004-05-19 at 18:08, Dave Boodman wrote:
> breakthrough!
Cool!
> 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;
> }
>
>
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->columns;
push @out, \%e;
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->columns;
push @out, \%e;
}
this does:
my
$db = Lib::Systems->dbh;
my $sth = $db->prepare("select *
On Wed, 2004-05-19 at 14:28, Dave Boodman wrote:
> 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
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,
Dave Boodman wrote:
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.
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
The way I know the view page is hitting different children is in the
logs, I have the PID of the child included in each log output:
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
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
On Tue, 2004-05-18 at 17:36, Dave Boodman wrote:
> By regular do you mean with each invocation?
I mean that it happens frequently enough that it's not likely to be tied
to some freak occurrence involving race conditions or other
inter-process issues.
> Cause I regularly see the same children not
Sorry, back to the list.
By regular do you mean with each invocation? Cause I regularly see the
same children not return the newly-inserted data, while (most) others
regularly return it fine. In -X, the single process always returns the
right data.
I've just run the update with the following cod
[ CC'ing the list ]
On Tue, 2004-05-18 at 16:53, Dave Boodman wrote:
> -X does what i thought - works perfectly.
That just means you haven't figured out the steps to recreate the
problem yet.
> I do see this whenever I first hit the web server after a restart, does
> this look normal (obviously
[ 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. so, i can call it on any
> old obj or do i have to (can i) create a special/new obj just to do the
> commit/rollback.
You can call it on any object,
Back to this issue, sorry, been in HI for 2 weeks :)
OK, here's some small(er) code I that repeats the problem. To recap, the
gist is, i'm adding an item (a "system") to a customer, and
post insert, the new item only shows up on certain page reloads - certain
children aren't seeing the newly inse
On Mon, 2004-05-17 at 18:55, Dave Boodman wrote:
> OK, here's some small(er) code I that repeats the problem.
Dave, this is really too much code, at least for me. It also refers to
lots more code that isn't shown here. If you go through the process of
reducing all of this to a small and complete
OK, here's some code:
# systems
my @statuses;
my (@systems) = Lib::Systems->search( cid => $cid );
unless (@systems) { $self->model->log('debug', "systems for '$cid' not
found"); $self->context->throw( 'systems.not_found', 'Systems not found' ); };
my $systems_profile = Lib::Pr
On Mon, 2004-05-03 at 13:15, Dave Boodman wrote:
> OK, here's some code:
This is a little too much code to look at without any direction. The
best thing to do would be to remove as much code as possible to get
things down to the smallest example that demonstrates the problem. You
should also tel
Hi Dave,
It looks like you are using Class::DBI. The behavior you describe is
exactly what you would see if you had uncommitted changes. The changes
would be visible to the connections that made the changes, but not to
the other processes or connections.
If the problem is easy to reproduce, you c
Dave Boodman wrote:
As Perrin said, it sounds like it might be a scoping issue with some variables
and how they are (not?) passed into subs. What could really help us spot it
are your subs and calls to them. In fact if you can reduce it to a very simple
test case that has the same experience, it w
OK, here's some code:
#
systems
my @statuses;
my (@systems) = Lib::Systems->search( cid
=> $cid );
unless (@systems) {
$self->model->log('debug',
"systems
for '$cid' not
found");
$self->context->throw(
'systems.not_found',
'Systems
not found' );
};
my $systems_profile =
Lib::
Dave Boodman wrote:
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.
Sounds like you have a scoping problem. You are pr
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
26 matches
Mail list logo
