Open Bug 278458 Opened 15 years ago Updated 11 years ago
Add columns to fielddefs indicating which database columns hold the values for that field
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.
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.
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.
(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.
(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.
Priority: -- → P2
Target Milestone: --- → Bugzilla 2.22
The trunk is now frozen to prepare Bugzilla 2.22. Enhancement bugs are retargetted to 2.24.
Target Milestone: Bugzilla 2.22 → Bugzilla 2.24
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?
(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.)
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.
Target Milestone: Bugzilla 3.2 → ---
You need to log in before you can comment on or make changes to this bug.