The Road to 2.18 - Customfields

[David Miller]

On 3/11/2004 9:20 PM -0800, Stuart Donaldson wrote:

> Joel Peshkin wrote:
>
>> 2) Creation of new fields can be done either using the web (preferred)
>> or localconfig/checksetup
>
> Someone recently posted a concern about using a web interface to create
> custom fields.  I share the concern that a web interface makes it too
> easy to add custom fields, and may encourage bad use of bugzilla.  I
> think it would make much more sense to be implemented via
> localconfig/checksetup such that it forces a little more forethought
> into the process.  Furthermore, I suspect a localconfig/checksetup
> solution would reduce the complexity of the implementation.

I also think a web interface is a bad idea.

My thinking is on the Database Independence track (which seems to be in
high gear now, as well, and will probably land on the trunk VERY shortly
after we branch for 2.18).

Many companies choose to have DBAs to handle their databases.  Most
companies who do this also have a requirement that nobody but the DBA can
make schema changes in the production databases.  The Bugzilla application
(and hence, probably the bugzilla admin) in such an environment will
probably not have sufficient access to the database to make schema changes.
Which means the DBA will be the one to run checksetup.pl (or the database
setup script once it gets separated out -- it will get separated at some
point due to the above), and specifying their own userID while doing it.

The current design calls for a dynamic way of defining custom fields
without making schema changes.  This is a lofty design goal, and really
good for keeping things simple for the admin.  But the performance on
queries is going to suck badly once you try to get querying working on
custom fields, because of all the extra table joins you need in order to
match the fields.

I remain convinced that the best way to get performance out of it is going
to be to add a column for each field to a single table (for fields that
aren't multi-selects, anyway -- joins for those are going to be
unavoidable) so that the entire table only has to be joined once, no matter
how many custom fields you have.  That table would basically be an add-on
to the bugs table, and would be a straight one-to-one join with a row for
each bug.  When you add a single-select or freeform field, it gets added as
a column in that table.

Which brings me back to schema changes...  A performant way to do custom
fields would require schema changes to set them up, so they would need to
be defined in a datafile that can be accessed by the database setup script.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/