Bug ID domain?

[Sean McAfee]

Bradley Baetz <bbaetz at acm.org> wrote:
>> >...I'd like to use a special bug_id to store the default value for a given
>> >field_id.  NULL is out, unfortunately, because I need that primary key.
>> >Would using a number like 0 or -1 be safe?

>Why not store the default as a column in the table which defines all of
>the fields? thats the sensible place for it.

You mean, augmenting the custom_fields table like so:

custom_fields
-------------
field_id integer primary key,
product smallint,
display_index integer not null,
field_name tinytext not null,
field_type char not null,
required bool not null,
extended bool not null,
selection_id integer,
#  new columns follow:
default_integer integer,
default_shortstr tinytext,
default_longstr text,
default_date date,
default_selection_label_id integer

...where exactly one of the new default_* columns is populated for any given
field, depending on its type?  That strikes me as a considerably worse hack
than what I proposed.

Hmmm.  Or did you mean, add a single extra column--called simply "default",
say--that holds the defaults for all field types?  It would have to be a
text column, to accomodate the largest custom field type.

Even a text column isn't large enough for all cases, though.  The default
value for a multiselection would have to be serialized in some way;
to a string like "1,2,3,4", presumably.  But the earlier consensus was
that the number of possible selection values should be unlimited, so the
serialization of a large multiselect default could exceed 64K characters.
Sure, probably no one *would* create such a huge default value, but the
design should allow for that possibility.  Besides which, I'd find it
much more elegant if data of all kinds are stored in the DB in their
most compact representation, with no munging required.


-- 
Sean McAfee -- etzwane at schwag.org