[ic] Matrix options and set_row possible bug?

Peter peter at pajamian.dhs.org
Thu Jun 22 17:42:57 EDT 2006


On 06/22/2006 09:03 AM, Jon Jensen wrote:
> Peter,
> 
> It is a known deficiency in some Interchange database routines that when 
> a new row is created, it's first created with only the primary key and 
> the remaining fields NULL, and then updated to populate the fields. 
> Obviously quite bad if you're using a well-designed database that 
> doesn't allow NULL all over the place.
> 
> I can't remember if that has been fixed in newer versions of Interchange 
> yet or not, but it's worth taking a look at the latest set_row and any 
> dependent routines in CVS.

I checked CVS and the only change to the set_row sub since the 5.2 
tagged revision was to add more info to one of the #logDebug lines, 
nothing that should affect this.  I'll look again, though, maybe there 
was a significant change to another sub.

> I will also note that it's pretty pointless to try to keep a tight data 
> model in the options table when you're using the old 4.8-style options, 
> because the table is not even remotely normalized: There are essentially 
> three different kinds of rows crammed into the same table, and it just 
> isn't a sane data model.
> 
> So you'd might as well just consider dropping the NOT NULL constraints 
> on options, as the table is fairly messy anyway. If you want to do 
> things a better way, look at the newer options introduced in (I think) 
> Interchange 5.2, using a separate variants table.

Yep, tried 5.2 options and it won't even let me into the Matrix editor 
for those at all.  I will give that another look.

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.

Peter


More information about the interchange-users mailing list