287322 - Move old enum fields into a generic code framework

Status: NEW

(Bugzilla :: Bugzilla-General, enhancement)

Description

[Max Kanat-Alexander]

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.

Comment 1

[Jason Bucata]

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.

Comment 2

[Max Kanat-Alexander]

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.

Comment 3

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 4

[Max Kanat-Alexander]

(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.    

Comment 5

[Max Kanat-Alexander]

*** Bug 349483 has been marked as a duplicate of this bug. ***

Comment 6

[Frédéric Buclin]

Per our discussion on IRC, shouldn't this bug be wontfix'ed?

Comment 7

[Max Kanat-Alexander]

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.

Comment 8

[Frédéric Buclin]

Doesn't block bug 287326 anymore, per comment 7. Removing it to have a dependency tree which is a bit more realistic.