Custom fields schema

Myk Melez myk at
Tue Jan 25 22:12:43 UTC 2005

Maxwell Kanat-Alexander wrote:

>On Tue, 2005-01-25 at 07:28 +0200, Vlad Dascalu wrote:
>>I agree with Myk. The FAC proposal makes more sense for me, from all 
>>points of view.
>	I also used to think so.
>	But if we want people to be able to write "plugins" for Bugzilla,
>Fields-As-Rows makes much more sense.
Plugins can be roughly divided into three categories:

    * add no new fields (NNF), just manipulate existing ones (f.e. a
      plugin that added a "checked in" comment and resolved bugs "FIXED"
      when a patch on them was checked into a source control system);
    * add new generic fields (NGF) that don't need to be manipulated
      specially and can be implemented using custom fields;
    * add new special fields (NSF) that need to be manipulated specially
      and cannot be implemented using custom fields (f.e. Test Runner

Of these, only NGF plugins can use custom fields, and if a plugin just 
creates a custom field and then lets the generic custom field code 
handle interaction with it, then why take the trouble to make it a 
plugin?  It'd be much easier for installations that want the 
functionality to just define the custom field themselves using whatever 
interface we develop for managing custom fields.

I think very few, if any, plugins will create custom fields.  But even 
if some did (f.e. a plugin that created a bunch of related custom fields 
which would otherwise be burdensome to create by hand via the interface, 
or a plugin which reused most generic custom fields code but with a few 
special tweaks), why does FAD make more sense for them?  Real columns 
are as easy to create programmatically, keep plugin data more separate 
from standard and installation-defined custom field data, and can be 
made more secure if necessary (by giving plugins a MySQL account that 
only permitted write access to its own tables).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the developers mailing list