Custom fields schema

[Nick Barnes]

On custom fields, I think that choosing a schema design for
performance reasons at this early stage is a classic example of
premature optimization.

It seems unlikely that any of the proposed schema designs [*] would
present insurmountable performance obstacles on current hardware with
the data volumes we're talking about (~2^20 bugs).  Furthermore, most
of the work for custom fields is not in the schema design, and in fact
is totally independent of the schema design.  As far as the central
functionality of custom fields is concerned, the data could be stored
in a shoe-box under my bed, or in the songs of a troupe of trained
Mesopotamian aardvarks [*2].

Plainly we should choose the simplest reasonable overall design and go
ahead and build a custom fields system and get it into the trunk.  If
that then turns out to be too slow, or too big, or insufficiently
lemon-scented, we can *then* optimize (for instance, by retro-fitting
one of the other schema designs).

I could certainly imagine a release (2.22, say) with a somewhat slow
and clunky custom fields system.  People who want custom fields could
then either (a) do without or (b) have slow custom fields.  If they
choose (b) and are unhappy, *then* they will raise bugs, and in the
comments on those bugs we can revisit the schema design.  Then 2.24 or
2.26 can have better faster whizzier custom fields.

For exactly analogous reasons, I think we should consider a first-cut
custom fields system which only provides a small number of custom
field types (maybe only one?) and layout options (a table below the
Keywords box?).  Users will then raise bugs saying "no timestamp
custom fields", or "custom fields not where I want them" or "custom
fields not in 16-point DingBats", and we can fix those bugs and move
on.

Ditto a first cut in which adding or modifying a custom field requires
the administrator to *edit a file* (or even to *type some MySQL*).  I
know that this puts me pretty far out on left field, but all my
industry experience has taught me the prime importance of evolutionary
delivery.

Let's do *something* [*4], then raise bugs describing all the myriad
ways in which it can be improved, then fix those bugs.  "I don't like
the schema design, I think it should be like this" is not a bug.  "It
is too slow" is a bug, but not one which can or should be raised until
someone actually has a Bugzilla which actually is too slow [*3].

Nick B

[*] I count three, at least:
    fields-as-columns-in-bugs-table;
    fields-as-columns-in-other-tables;
    fields-as-data.

[*2] very rare.

[*3] As I understand it, Sean actually has a Bugzilla with his custom
fields extension in it, and presumably that isn't too slow.

[*4] No, this is not the fallacy: "Something must be done; this is
something; therefore this must be done".  I'm not advocating doing
just anything; I'm advocating doing some small thing which works.