More on custom fields
bugreport at peshkin.net
Tue Dec 14 14:40:18 UTC 2004
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.
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)
More information about the developers