Open Bug 106589 Opened 24 years ago Updated 12 years ago

one of the resolutions is an empty string

Categories

(Bugzilla :: Database, defect, P3)

Product:
Bugzilla
Component:
Database
Version:
2.15
Type:
defect

Tracking

()

People

(Reporter: myk, Unassigned)

References

(Blocks 1 open bug)

Details

The ENUM for the bugs.resolutions column contains an empty string as one of the values. There should be no such thing. Either a bug should have no resolution (in which case the field should contain the NULL value) or it should have a named resolution.
This value is for unresolved bugs. I supposed we could change it to NULL.
Good idea. Unresolved bugs have no resolution, which is exactly what "NULL" means: no value.
OK, here's the drill. Customised resolutions (bug #94534) will change this to ID 0. This is not necessarily best practice, but it is standard Bugzilla practice - see bugs.qa_contact for example.
See my comment in bug 94534 about this.
Mine.
Assignee: justdave → matty
Will do something about this on CUST_RES_BRANCH.
Priority: -- → P3
Target Milestone: --- → Bugzilla 2.16
Status: NEW → ASSIGNED
Done and waiting for landing.
You'll need to take out a hack that's in the to-be-checked-in query.cgi which removes this value, as you check in. This bug number is referenced next to the hack. Gerv
Hack to remove this value? Am I misinterpreting? This would severely break Bugzilla!
OK, you're referring to the legal_resolution list, etc, as opposed to the database schema. I'm suprised this hasn't caused problems elsewhere if its the case.
We are currently trying to wrap up Bugzilla 2.16. We are now close enough to release time that anything that wasn't already ranked at P1 isn't going to make the cut. Thus this is being retargetted at 2.18. If you strongly disagree with this retargetting, please comment, however, be aware that we only have about 2 weeks left to review and test anything at this point, and we intend to devote this time to the remaining bugs that were designated as release blockers.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
qa_contact has the same issue, with 0 rather than NULL. I need to clean up the schema post-2.16 for these sort of issues.
Accounts are bug #109474.
See also bug 86791
Severity: normal → enhancement
Enhancements which don't currently have patches on them which are targetted at 2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. Consideration will be taken for moving items back to 2.18 on a case-by-case basis (but is unlikely for enhancements)
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004. Anything flagged enhancement that hasn't already landed is being pushed out. If this bug is otherwise ready to land, we'll handle it on a case-by-case basis, please set the blocking2.20 flag to '?' if you think it qualifies.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Depends on: bz-custres
This also poses a problem when using Oracle, since Oracle doesn't allow empty strings in NOT NULL columns and RESOLUTION.VALUE currently has a NOT NULL constraint. (See bug 309663 for details.) Fixing this bug will remove one of the occurrences of that bug.
lance says it's a problem for Oracle, so it's a 2.24 thing... and a bug.
Assignee: mattyt-bugzilla → administration
Severity: enhancement → normal
Status: ASSIGNED → NEW
QA Contact: mattyt-bugzilla → default-qa
Target Milestone: Bugzilla 2.22 → Bugzilla 2.24
(In reply to comment #17) > This also poses a problem when using Oracle, since Oracle doesn't allow empty > strings in NOT NULL columns and RESOLUTION.VALUE currently has a NOT NULL > constraint. (See bug 309663 for details.) Fixing this bug will remove one of > the occurrences of that bug. Oh dear... that's a whole new can of worms. We have NOT NULL columns *all over* the place that have empty strings in them. Let's discuss it in bug 309663 or a new bug.
We are freezing the code for 3.0 in two weeks and we don't expect this bug to be fixed on time.
Target Milestone: Bugzilla 3.0 → ---
Are we planning to use NULL as the value of bugs.resolution for unsolved bugs? I notice the current code is still using ""(empty string) as resolution of unsolved bugs.
(In reply to comment #21) > Are we planning to use NULL as the value of bugs.resolution for unsolved bugs? Yeah, that would be ideal, I think. We might still stick with '' though, I don't know.
I also think "" should go away and be replaced by NULL. And custom values already forbird "" anyway. - This change wouldn't break tabular/graphical reports as they are already broken, see bug 212471. - Old charts do not let you plot anything against the "" resolution already, so this behavior wouldn't change. - New charts simply display existing queries which already use the conversion &resolution=--- <-> "resolution IS ''", as any other "normal" query. So all we would have to fix (AFAIK) is to change this conversion to &resolution=--- <-> "resolution IS NULL". This means we don't even need to fix saved searches/new charts as they wouldn't be affected. - And thanks to the refactoring done against process_bug.cgi, we would have a single place to fix: $bug->set_resolution() to set the resolution to undef instead of "". I would say "do it!" and we will fix what's broken due to this change. It would be fine to do this change early in a release development (e.g. Bugzilla 3.4). Oh, that's now! :)
Assignee: administration → database
Component: Administration → Database
You need to log in before you can comment on or make changes to this bug.