Re: Wierd update behaviour in 0.96
[prev]
[thread]
[next]
[Date index for 2004/06/01]
--=====================_93300593==.ALT
Content-Type: text/plain; charset="us-ascii"
At 02:57 PM 6/1/2004, Perrin Harkins wrote:
>On Tue, 2004-06-01 at 00:40, John Day wrote:
>> Using the following database table (it is one in my normal development
>> database) and the test code and the myCDBI.pm module I can replicate
>> the problem. When the code is run unmodified (with the $alter_int
>> object having the update method run on it) the second call to
>> &disp_data produces no output.
>
>This code is kind of hard to follow. Especially this bit:
>
>> my $results = $alter_int->hash;
>> $alter_int->set( %{$results} );
>> $alter_int->update;
>
>What is that supposed to do? It looks like it's intended to do nothing
>at all.
Well, kinda! The data normally comes form a form, this was done to get the record, convert it to a hash and just write it back to the table.
>> $g = hashy($g) if ref $g;
>
>"hashy"? Who is that?
An error. hashy should have been hash. We just recurse through the returned object to inflate references - if any.
>I would suggest reducing this code more to find out what's going on.
>I'd try a simple update and see what happens, cutting out that
>$alter_int->hash stuff.
I did, and here is the conclusion.
If we send include the PRIMARY KEY as a column to be updated then we get the problem. IN the case of this table:
$alter_int->set( 'intend' => '17:53:00', 'intervalid' => 9 );
will fail - not returning any data when we attempt to read the record back, despite the table having been updated in the database. BUT
$alter_int->set( 'intend' => '17:53:00');
causes the update to take place AND the record can be read back again.
This behaviour was not evident in 0.94, I installed that on another server today and if the PRIMARY KEY is passed to the set method it seems to ignore it.
Thank you very much for the assistance - and the gentle prod in the right direction!
John
>- Perrin
--=====================_93300593==.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<body>
At 02:57 PM 6/1/2004, Perrin Harkins wrote:<br>
<blockquote type=cite class=cite cite>On Tue, 2004-06-01 at 00:40, John
Day wrote:<br>
> Using the following database table (it is one in my normal
development<br>
> database) and the test code and the myCDBI.pm module I can
replicate<br>
> the problem. When the code is run unmodified (with the
$alter_int<br>
> object having the update method run on it) the second call to<br>
> &disp_data produces no output.<br><br>
This code is kind of hard to follow. Especially this bit:<br><br>
> my $results = $alter_int->hash;<br>
> $alter_int->set( %{$results} );<br>
> $alter_int->update;<br><br>
What is that supposed to do? It looks like it's intended to do
nothing<br>
at all.</blockquote><br>
Well, kinda! The data normally comes form a form, this was done to get
the record, convert it to a hash and just write it back to the
table.<br><br>
<br>
<blockquote type=cite class=cite cite>> $g = hashy($g) if ref
$g;<br><br>
"hashy"? Who is that?</blockquote><br>
An error. hashy should have been hash. We just recurse through the
returned object to inflate references - if any.<br><br>
<br>
<blockquote type=cite class=cite cite>I would suggest reducing this code
more to find out what's going on. <br>
I'd try a simple update and see what happens, cutting out that<br>
$alter_int->hash stuff.</blockquote><br>
I did, and here is the conclusion.<br><br>
If we send include the PRIMARY KEY as a column to be updated then we get
the problem. IN the case of this table:<br><br>
$<font color="#A000F0">alter_int-</font><font color="#B22200">></font>set(
<font color="#0000FF">'intend'</font> <font color="#B22200">=></font>
<font color="#0000FF">'17:53:00'</font>, <font color="#0000FF">'intervalid'</font> <font color="#B22200">=></font> <font color="#A02000">9</font> );<br><br>
will fail - not returning any data when we attempt to read the record back, despite the table having been updated in the database. BUT<br><br>
$<font color="#A000F0">alter_int-</font><font color="#B22200">></font>set( <font color="#0000FF">'intend'</font> <font color="#B22200">=></font> <font color="#0000FF">'17:53:00'</font>);<br><br>
causes the update to take place AND the record can be read back again.<br><br>
This behaviour was not evident in 0.94, I installed that on another server today and if the PRIMARY KEY is passed to the set method it seems to ignore it.<br><br>
Thank you very much for the assistance - and the gentle prod in the right direction!<br><br>
John<br><br>
<br><br>
<br><br>
<blockquote type=cite class=cite cite>- Perrin</blockquote></body>
</html>
--=====================_93300593==.ALT--
