Partial custom fields design document

[Joel Peshkin]

Daniel Berlin wrote:

>>> People like Sean have tried to do this, but the discussion seems to 
>>> be complicating things more and more...
>>
>>
>> That's because it _is_ complicated :-)
>>
>
> Only because it's continually being made more and more complicated by 
> nit-picking it to death.
> It doesn't have to be extremely complicated.
>
The proposal is not being held up by nit-picking, even though most of 
the discussion seems to be centered around addressing the nits and 
ignores the central issues...

The central issues are....
1) Should fields with a 1:1 relationship to bugs be
     a) placed in distinct fields of either bugs or another table that 
has a 1:1 relationship to bugs
   or
     b) placed in a table that needs to be joined to bugs once for each 
field

1.5) Whatever is done must not trash performance on huge systems.

2) Should customfields be something that get created in the DB through 
the web interface or should that function be seperate

3) Not a question, a statement...
      Bugs activity must work.  Search must work. Bugmail must work.  
Localization must work

(That said, I have been advocating addressing localization of custom 
fields by letting the database support ONE language and letting a site 
override that with templates if they want to and need to support more 
than one language.)

So, please stop wangling on the nits and work to converge on the central 
issues.

If you feel picked on, look at how many iterations of the design 
documents I went through on the group system rewrites. :-)

-Joel