| 2012-08-30 15:35:53 |
Abel Deuring |
description |
unning 'grep "3, 4, 5" *' in database/schema returns these hits:
patch-2209-11-4.sql: IF bug_row.information_type NOT IN (3, 4, 5) THEN
patch-2209-12-3.sql: IF (bug_row(OLD.bug)).information_type IN (3, 4, 5) THEN
patch-2209-12-3.sql: IF OLD.bug <> NEW.bug AND (bug_row(NEW.bug)).information_type IN (3, 4, 5) THEN
patch-2209-12-3.sql: IF (bug_row(OLD.bug)).information_type IN (3, 4, 5) THEN
patch-2209-12-3.sql: IF OLD.bug <> NEW.bug AND (bug_row(NEW.bug)).information_type IN (3, 4, 5) THEN
patch-2209-12-3.sql: AND $1.information_type IN (3, 4, 5);
patch-2209-16-0.sql: IF information_type IN (3, 4, 5) THEN
patch-2209-16-6.sql: IF information_type IN (3, 4, 5) THEN
patch-2209-19-0.sql: WHERE $1.information_type IN (3, 4, 5);
patch-2209-19-3.sql: WHERE $1.information_type IN (3, 4, 5)
patch-2209-19-3.sql: WHERE $1.information_type IN (3, 4, 5);
ISTM that this is already outdated: The enum InformationType defines
another non-public type EMBARGOED, represented as the number 6.
We should
- define a DB procedure which returns the numbers for private values in
InformationType,
- use this procedure in the other DB procedures instead of simply
specifying the numbers themselves
- add a unit test which checks that this procedure returns the same
numbers as those appearing in lp.registry.enums.PRIVATE_INFORMATION_TYPES
I also think that the procdures should be more thoroughly checked for
the usage of these numbers -- grepping for "3, 4, 5" may of course miss
some places where information_type valöues are checked.
And it might make sense to replace "information_type IN <all-private-values>"
with "NOT information_type IN <all-public-values>" |
Running 'grep "3, 4, 5" *' in database/schema returns these hits:
patch-2209-11-4.sql: IF bug_row.information_type NOT IN (3, 4, 5) THEN
patch-2209-12-3.sql: IF (bug_row(OLD.bug)).information_type IN (3, 4, 5) THEN
patch-2209-12-3.sql: IF OLD.bug <> NEW.bug AND (bug_row(NEW.bug)).information_type IN (3, 4, 5) THEN
patch-2209-12-3.sql: IF (bug_row(OLD.bug)).information_type IN (3, 4, 5) THEN
patch-2209-12-3.sql: IF OLD.bug <> NEW.bug AND (bug_row(NEW.bug)).information_type IN (3, 4, 5) THEN
patch-2209-12-3.sql: AND $1.information_type IN (3, 4, 5);
patch-2209-16-0.sql: IF information_type IN (3, 4, 5) THEN
patch-2209-16-6.sql: IF information_type IN (3, 4, 5) THEN
patch-2209-19-0.sql: WHERE $1.information_type IN (3, 4, 5);
patch-2209-19-3.sql: WHERE $1.information_type IN (3, 4, 5)
patch-2209-19-3.sql: WHERE $1.information_type IN (3, 4, 5);
ISTM that this is already outdated: The enum InformationType defines
another non-public type EMBARGOED, represented as the number 6.
We should
- define a DB procedure which returns the numbers for private values in
InformationType,
- use this procedure in the other DB procedures instead of simply
specifying the numbers themselves
- add a unit test which checks that this procedure returns the same
numbers as those appearing in lp.registry.enums.PRIVATE_INFORMATION_TYPES
I also think that the procdures should be more thoroughly checked for
the usage of these numbers -- grepping for "3, 4, 5" may of course miss
some places where information_type values are checked.
And it might make sense to replace "information_type IN <all-private-values>"
with "NOT information_type IN <all-public-values>" |
|
