More on custom fields

[Joel Peshkin]

Paulo,

   I agree with both the goal and general plan you propose.  Past 
efforts to get a customfields plan together have all gotten stalled by a 
lack of benchmarking.  There are major schema decisions to be made.  
Each time the subject comes up,  the discussion stalls as nobody has 
volunteered to create a large (dummy) test database and benchmark 
proposed queries to test performance.

   The other item we should consider is how to break the plan up into 
steps that can land independently where possible.

    Some thoughts...
1) I suspect that fielddefs can be expanded to let more of the code 
figure out how to handle fields than we currently do.  Expanding the 
role of fielddefs, with a future cutomfields implementation in mind, 
could vastly reduce the number of places in the code that need to know 
any specifics about all of the fields.  Right now, there are often over 
20 places in the code that have to be hacked to add a new field.
2) We should initially forego a UI for managing customfields and let it 
be done by checksetup (populating an enhanced fielddefs table, for 
instance).  Initially, we should also assume that users of customfields 
will add support for the new fields in their templates.
3) After we have the right schema for customfields working properly with 
all of the processing, bugmail, and query code and have landed the 
patches up to that point; then we can begin to add an administrative UI 
and default handling of customfields in templates.  (I say default 
handling because we probably want to be able to accept a simple 
automatic presentation or use a hand-crafted template implementation)

-Joel