An alternate approach to custom fields

[Gervase Markham]

Sean McAfee wrote:
> "Jon Wilmoth" <JWilmoth at starbucks.com> wrote:
> As for me, I need at least a few days to become more familiar with the code
> and schema.  Then, I was planning to write up a requirements document and
> solicit comments...unless someone else takes the helm in the meantime, I
> suppose.

bbaetz outlined how we would like this to work in a message on the 1st 
of this month:

>>A Google for 'database "mapping tables"' doesn't define the term. Do you 
>>> mean lots of tables like:
> 
> No, I mean tables like:
> 
> bug_id, field_id, value
> 
> We will need several of those, however - one for string types, and one
> for number types, so that indexes work optimally. For stuff like os's,
> (field_id, value) is an FK [Foreign Key] to another table which has the
> name<-> number mapping.
> 
> (If we ever support email types that way, then wed need a third one, to
> fk to the profiles table)
> 
>>> with slight variations depending on whether it's a 1->1 or 1->many or 
>>> enum-style mapping? And doing joins everywhere to connect it all up?
> 
> 1->1 vs 1->many is only how many entries there are. We may want
> (another) separate table for that to add the UNIQUE constraint - I
> haven't thought too much about that.

Basically, you need to run your design past him. If he likes it, we like 
it :-) Here are some thoughts.

Important criteria:

- If you aren't using custom fields, performance should not be affected

Possible field types:
- Single string
- Single value from enum (but can't use MySQL-specific ENUM type)
- Single email address (optional, unless you need it yourself)
- Multiple values from enum (optional)
- Multiple email addresses (very optional)

We need to discuss and find good UI for displaying the custom fields on 
the show_bug page, and querying for them.

Gerv