Re: Testing 1.7: issues in edit grid & query window

Erwin Brandstetter wrote:
> Hi developers! Hi Dave!

Hi Erwin,

Edit grid first - will follow up later with the others (it's easier for
me to deal with each distinct subject in separate messages)

> Edit grid
> =========
>
> The edit grid suppresses NULL values ON INSERTs (UPDATEs are not
> affected). Example. Say we have a table:
>
>    CREATE TABLE mankind
>    (
>      man_id integer primary key,
>      people_id integer,
>      king boolean DEFAULT false
>    );
>
> When I enter "24 for "man_id", "2" for "people_id" and do not enter
> anything for "king" in the edit grid this statement is sent to the
> database:
>    INSERT INTO mankind(man_id, people_id) VALUES ('24'::integer,
> '2'::integer)
> Which is correct.
>
> When I do the same, but explicitly select NULL in the control for the
> boolean field king, though, the statement will still be the same:
>    INSERT INTO mankind(man_id, people_id) VALUES ('24'::integer,
> '2'::integer)
> Which is wrong.

After figuring out why, and modifying it to work as you suggest, it
strikes me that actually it's not wrong imho. In all cases, the edit
grid currently takes null-on-insert to mean 'don't insert this value'.
This ensures that default values for the column will always be respected
upon insert - for example, leave a text column empty, and it'll pick up
it's default value. If we made empty/blank/undetermined consistently
force the value to NULL, there would be no way to pickup the default
value for a column. As it is now, the worst case is a 2nd edit is
required to reset a column with a default value back to null.

It is possible to change this of course by having a quad state checkbox
for booleans, and allowing a keyword such as <DEFAULT> to be entered
into other types. There are a couple of problems with that, not least of
which is that we'd need to create a custom checkbox control because we
only have tri state ones at present. We'd also need to figure out some
way to actually enter <DEFAULT> into a text column in case that was a
legitimate data value for some people, and to alllow those characters in
a numeric column, but only in that order, and on their own.

I'm not sure this is ever likely to get fixed to be honest.

Regards, Dave.