[ic] Matrix options and set_row possible bug?

[Peter]

On 06/22/2006 02:53 PM, Jon Jensen wrote:
> On Thu, 22 Jun 2006, Peter wrote:
> 
>> I may see if I can fix both because the first mentioned bug would pay 
>> to help everyone out if I can fix it.  I think it's branching wrong in 
>> set_row (from looking it should be branching to a different part of 
>> the function if only the key is defined, but it's not) so I'll see if 
>> I can figure out why.  I've got a change in mond of using DEFAULT 
>> instead of the '?' placeholder for fields that don't exist in the 
>> @fields array, that may go a long ways towards fising it, but it would 
>> also require changing the number of bindings or the db will error out 
>> because of a mismatch of bindings to ?'s.
> 
> I'd like to see a fix for this key-only problem if you fix it.

Well I just figured out the problem.  I'm trying to think of the best 
solution right now.  The problem is in this block of code in set_row:

         if ($cfg->{PREFER_NULL}) {
                 for (keys %{$cfg->{PREFER_NULL}}) {
                         my $i = $cfg->{COLUMN_INDEX}{$_};
                         undef $fields[$i] if $fields[$i] eq '';
                 }
         }

I believe that is supposed to set any fields which are set as 
PREFER_NULL and have the empty string to NULL. The problem is that the 
if $fields[$i] eq '' returns true for undefined as well, so it causes 
$fields[i] to explicitly be set to undefined which causes the array to 
be expanded out to i-1 elements, and all of the expanded out elements 
are set to undefined by default which DBI translates to NULL.

I can think of a few simple solutions, moving this block down below the 
next if(scalar @fields == 1) { block would probably fix it and I'm 
inclined to do that which will probably be enough to fix the problem as 
long as @fields either contains only one element or a number of elements 
to equal the number of fields in the table.  If set_row is ever called 
with @fields having somethign in between then there will still be problems.

Peter