Bug ID domain?

[Bradley Baetz]

On Thu, Apr 24, 2003 at 07:12:52PM -0400, Sean McAfee wrote:
> 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:
> #  new columns follow:
> default_integer integer,
> default_shortstr tinytext,
> default_longstr text,
> default_date date,
> default_selection_label_id integer

Sort of. Here (and here _only_), you can get away with a single text
value. This is because we've never going to query on this value, and all
we are going to do with it is display it to the user (on enter_bug) as
text anyway.

> 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.

Right.

> 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.

I thought mulitselects were out of the first version? I really need to
look at the next draft of the proposal - I just haven't had time
recently. Hopefully this weekend.

Hmm. Maybe putting it into the data table will work. You'd have to use
NULL (not 0, or anything else) so that FKs will work. (Besides, NULL is
the 'correct' thing here)

> 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.

But it does't matter here, because theres no querying involved. It
matters for the real data since that affects the indexing/comparison
operations.

Anyway, I've changed my mind; NULLs in the data table should be fine.
Thoughts?

Bradley