278458 - Add columns to fielddefs indicating which database columns hold the values for that field

Status: NEW

(Bugzilla :: Bugzilla-General, enhancement, P1)

Description

[Max Kanat-Alexander]

fielddefs should have two columns that indicate which database columns hold
valid values for that field.

The two columns would be: value_id varchar, and value_displayed varchar. These
would both hold the fully-qualified name of a column in the database.

For example, for products, they would be:
value_id: "products.id"
value_displayed: "products.name"

In general, this can help a lot with automation of code in the backend, to
validate values and so forth without having to special-case things and create
new functions for each enumerated field that we have.

Comment 1

[Dave Miller [:justdave]]

In the example you cited I think the value_id would actually be bugs.product_id

I think there's already a column in fielddefs intended to show the value_id
equivalent that you're suggesting here.  I think that column has actually been
used for both, and we may have some duplicates along those lines which should be
merged.

Comment 2

[Joel Peshkin]

Actually, while we are thinking about Fielddefs, there are a lot of things we
should be able to use Fielddefs for.  If you look through the code at all the
places there are hardcoded lists of field names, most of those should be able to
go away.

If we extend this to have a little more type information, I think we can fix
many the places that do ANYTHING with checking of legal ENUM types.  We have to
be a bit more careful with "GetSelectable****" situations, but let's see hom
much of the problem we can nail here.

In my ideal scenario, Fielddefs would be able to provide field lists for all the
places where they are needed and would know which GetSelectable**** funtion is
needed as well as where to get the value lists.

Comment 3

[Max Kanat-Alexander]

(In reply to comment #1)
> In the example you cited I think the value_id would actually be 
> bugs.product_id

  No, it would be product.id. The additional table columns should basically be a
"name to id translator", or just a field that says "where are the valid values
for this enumerated type kept" (in the case where value_id is NULL).

> I think there's already a column in fielddefs intended to show the value_id
> equivalent that you're suggesting here.

  Which column is that? I know that there's one column that says what the bug
field name is in the bugs table, but that won't get me what I need out of the
other tables that hold enumerated values.

Comment 4

[Max Kanat-Alexander]

(In reply to comment #2)
> In my ideal scenario, Fielddefs would be able to provide field lists for all the
> places where they are needed and would know which GetSelectable**** funtion is
> needed as well as where to get the value lists.

  Yeah. In fact, I think that we could collapse all "GetSelectable" functions
into one function, and just pass it the name of the field, or the field id.

Comment 5

[Frédéric Buclin]

The trunk is now frozen to prepare Bugzilla 2.22. Enhancement bugs are retargetted to 2.24.

Comment 6

[A. Karl Kornel]

2 questions:

1) mkanat: Are you working on this bug?

2) Does this bug just handle creating the DB columns, or creating them and populating all of the values?

Comment 7

[Max Kanat-Alexander]

(In reply to comment #6)
> 1) mkanat: Are you working on this bug?

  I am not, at the moment.

> 2) Does this bug just handle creating the DB columns, or creating them and
> populating all of the values?

  Creating them and populating their values.

  We also should have code that uses them before checking in any code from this bug. (So we'd need at least one dependency ready to check in simultaneously with this.)

Comment 8

[Max Kanat-Alexander]

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?". Then, either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

This particular bug has not been touched in over eight months, and thus is being retargeted to "---" instead of "Bugzilla 4.0". If you believe this is a mistake, feel free to retarget it to Bugzilla 4.0.