Open Bug 287322 Opened 16 years ago Updated 14 years ago

Move old enum fields into a generic code framework

Categories

(Bugzilla :: Bugzilla-General, enhancement)

2.19.2
enhancement
Not set
normal

Tracking

()

People

(Reporter: mkanat, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

Right now, we have a lot of fields like "resolution", "bug_status",
"rep_platform", etc. They all have an individual table for what their allowed
values are.

Instead, they should have a single table. It should work in the same way that
setting_value works, most likely.

Each field should be moved to this table one-at-a-time, if this is possible. I
won't file blocker bugs for each field until I'm certain that it's actually
possible and easy to move them one-at-a-time.
Summary: Movoe old enum fields into a generic framework where all values are in a single table → Move old enum fields into a generic framework where all values are in a single table
Blocks: bz_select
Blocks: 287335
I'm assuming you're talking about a relational database table in the back end
somewhere...  Are you using referential integrity on those tables?  If so, you
won't be able to combine them, unless you're willing to let any value in the
lookup table be valid for any of those fields--so you could have "WONTFIX" as a
value in "rep_platform", etc.

If you're not using referential integrity, and are enforcing your lookup
constraints in code... IMPO it's best to at least leave yourself the option of
adding referential integrity in the future.  But whatever.

If you're not talking about a backend database at all... just ignore me ;).

This is from my years of database development experience, not from personal
knowledge of Bugzilla.  Apologies if this doesn't make sense; I'm just hoping to
save you some pain.
Oh, there will be a field_id field, so that will solve the problem of
referrential integrity. :-)

You're right, it's just that I was filing a million bugs at the same time when I
filed this one, and I didn't have time to go into detail about how it would work.
We shouldn't do this.  First, as Jason points out, we wouldn't be able to use
foreign keys to enforce referential integrity, which we want to do eventually. 
Second, it means expressing schema with data instead of structure, a suboptimal
approach.  Third, we couldn't cleanly extend the values of various fields with
additional attributes that don't apply to every field.
(In reply to comment #3)
> We shouldn't do this.  First, as Jason points out, we wouldn't be able to use
> foreign keys to enforce referential integrity,

  That's not entirely true. We could have a value_id field, or even perhaps a
combined key.

> Second, it means expressing schema with data instead of structure, a 
> suboptimal approach. 

  In this case, it makes for a much easier approach, I think, because it's easy
to write the perl code that deals with all the field values in a generic way, then.

> Third, we couldn't cleanly extend the values of various 
> fields with additional attributes that don't apply to every field.

  Those fields would/could stay in their own tables.

  You could be right, though.

  So let's just say that all these fields need to be in a generic framework of
*some* sort.    
Summary: Move old enum fields into a generic framework where all values are in a single table → Move old enum fields into a generic framework
*** Bug 349483 has been marked as a duplicate of this bug. ***
Per our discussion on IRC, shouldn't this bug be wontfix'ed?
Well, there could at least be generic *code* for all of them, since they're all just a Bugzilla::Field implementation.

But yes, the generic DB table is something we won't be doing.
Summary: Move old enum fields into a generic framework → Move old enum fields into a generic code framework
Doesn't block bug 287326 anymore, per comment 7. Removing it to have a dependency tree which is a bit more realistic.
No longer blocks: bz_select
You need to log in before you can comment on or make changes to this bug.