Closed Bug 505165 Opened 15 years ago Closed 14 years ago

The flags.setter_id DB column cannot be NULL

Categories

(Bugzilla :: Database, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Bugzilla 4.0

People

(Reporter: LpSolit, Assigned: LpSolit)

Details

Attachments

(1 file, 1 obsolete file)

A flag always has a setter. The DB should enforce this (it already has a FK pointing to profiles.userid). NOTNULL => 1 is missing.
Isn't it NULL when there's only a requester and no responder?
No idea what a responder is. Do you mean requestee? A flag has two user fields, one setter/requester (flags.setter_id, which must always be set), and the requestee (flags.requestee_id).
By responder I mean the person who grants +/-. I thought that if you just requested a flag, then requester_id was set, but setter_id was not.
Max, I wrote:

 $dbh->bz_alter_column('flags', 'setter_id', {TYPE => 'INT3', NOTNULL => 1});

but Pg crashes with:

Adding foreign key: flags.setter_id -> profiles.userid...
DBD::Pg::db do failed: ERROR:  constraint « fk_flags_setter_id_profiles_userid » for table « flags » already exists at Bugzilla/DB.pm line 515
        Bugzilla::DB::bz_add_fk('Bugzilla::DB::Pg=HASH(0xa2e6130)', 'flags', 'setter_id', 'HASH(0xa342250)') called at Bugzilla/DB.pm line 450
        Bugzilla::DB::bz_setup_foreign_keys('Bugzilla::DB::Pg=HASH(0xa2e6130)') called at Bugzilla/Install/DB.pm line 593
        Bugzilla::Install::DB::update_table_definitions('HASH(0x8a847b0)') called at ./checksetup.pl line 192
 at Bugzilla/DB.pm line 515
        Bugzilla::DB::bz_add_fk('Bugzilla::DB::Pg=HASH(0xa2e6130)', 'flags', 'setter_id', 'HASH(0xa342250)') called at Bugzilla/DB.pm line 450
        Bugzilla::DB::bz_setup_foreign_keys('Bugzilla::DB::Pg=HASH(0xa2e6130)') called at Bugzilla/Install/DB.pm line 593
        Bugzilla::Install::DB::update_table_definitions('HASH(0x8a847b0)') called at ./checksetup.pl line 192


Why is checksetup.pl trying to add the FK again?
(In reply to comment #4)
> Why is checksetup.pl trying to add the FK again?

  Hmm, dunnow--could be a bug. Does it still happen if you create a fresh database and then apply your patch and run checksetup again?
Target Milestone: --- → Bugzilla 3.8
Whiteboard: [Good Intro Bug]
Attached patch patch, v1 (obsolete) — Splinter Review
OK, I cannot reproduce the error mentioned above. I was probably playing with a broken DB (due to another patch I was testing).
Assignee: database → LpSolit
Status: NEW → ASSIGNED
Attachment #482076 - Flags: review?(mkanat)
Attached patch patch, v1Splinter Review
Oops, I missed one file.
Attachment #482076 - Attachment is obsolete: true
Attachment #482077 - Flags: review?(mkanat)
Attachment #482076 - Flags: review?(mkanat)
Attachment #482077 - Flags: review?(mkanat) → review+
Flags: approval4.0+
Flags: approval+
Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/trunk/
modified Bugzilla/DB/Schema.pm
modified Bugzilla/Install/DB.pm
Committed revision 7532.

Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/4.0/
modified Bugzilla/DB/Schema.pm
modified Bugzilla/Install/DB.pm
Committed revision 7435.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [Good Intro Bug]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: