Impact Table Implementation

[Kevin Benton]

Bill Barry wrote:
> It looks neat, I am not sure what you are trying to accomplish though.
> Is this something like "any bug in product 1.component a version x 
> automatically creates a bug in product 2.component b version y"
That's exactly what I'm after. :)  To give a more concrete example, when 
a bug is found in Mozilla Sunbird version x, it's known that it's likely 
to also impact the corresponding Lightning extension version as well.  
Therefore, file both bugs simultaneously unless the user specifies not 
to, making the auto-filed bugs dependent on the manually filed bug.  
Since "stuff" is reusable, we want to be aware when something that's 
been re-used has a bug in it and notify the proper "officials" that it's 
likely that the re-used "thing" has problems.  The "official" can then 
decide whether or not to keep the issue or discard it.

In our case, we've chosen specifically not to cascade impacts because of 
the mess it'll be likely to create.  So, if A impacts B (specified in 
the impact_map table) and B impacts C (similarly specified), filing a 
bug against A auto-files a bug against B, but not C because no impact 
has been directly specified in the impact_map table.  This also prevents 
impact loops (A depends on B depends on C depends on A).  Any impact 
that is not explicitly specified is not offered to users.

I almost forgot to add - there is another field in the impact_map table 
- is_optional which specifies when an impact can be turned off by a 
user.  So - if issues in Product A always impact Product B, the user is 
not given the option to turn off auto-filing of the additional bug 
(assuming is_optional is set to false).

Kevin
> or more along the lines "any bug in product 1.component a version x 
> has some affect on: (p2.comp b v.y, p2.comp c v.z, p1.comp a v.x-1)"
>
> Kevin Benton wrote:
>> Hi all,
>>
>> I'm implementing an impact table where product/component/version A 
>> impacts product/component/version B.  As a result, we're 
>> auto-creating a bug for B when a bug for A is created.  My challenge 
>> is determining how others think this should be implemented.  I've 
>> already made these changes to the versions table:
>>
>>     versions => {
>>         FIELDS => [
>>             value         =>  {TYPE => 'varchar(64)', NOTNULL => 1},
>>             product_id    =>  {TYPE => 'INT2', NOTNULL => 1},
>>             component_id  =>  {TYPE => 'INT2', NOTNULL => 0},
>>         ],
>>         INDEXES => [
>>             versions_product_id_idx   => {FIELDS => [qw(product_id 
>> value)],
>>                                           TYPE => 'UNIQUE'},
>>             versions_component_id_idx => {FIELDS => [qw(product_id
>>                                                         component_id
>>                                                         value)],
>>                                           TYPE => 'UNIQUE'},
>>         ],
>>     },
>>
>> Note the addition of the component_id and the allowance for it being 
>> NULL.  In other words, this allows for a no-impact change to the rest 
>> of Bugzilla but allows me to specify versions at the component level.
>>
>> Next, I am creating impacts and impact_map tables:
>>
>>     impacts => {
>>         FIELDS => [
>>             impact_id     =>  {TYPE => 'MEDIUMSERIAL',
>>                                NOTNULL => 1,
>>                                PRIMARYKEY => 1},
>>             product_id    =>  {TYPE => 'INT2', NOTNULL => 1},
>>             component_id  =>  {TYPE => 'INT2', NOTNULL => 0},
>>             version       =>  {TYPE => 'varchar(64)', NOTNULL => 1},
>>         ],
>>         INDEXES => [
>>             impactss_product_id_idx =>   {FIELDS => [qw(product_id 
>> version)],
>>                                           TYPE => 'UNIQUE'},
>>             impactss_component_id_idx => {FIELDS => [qw(product_id
>>                                                         component_id
>>                                                         version)],
>>                                           TYPE => 'UNIQUE'},
>>         ],
>>     },
>>    
>>     impact_map => {
>>         FIELDS => [
>>             impacting_id =>  {TYPE => 'INT3', NOTNULL => 1},
>>             impacted_id  =>  {TYPE => 'INT3', NOTNULL => 1},
>>         ],
>>         INDEXES => {
>>             impact_map_idx => {FIELDS => [qw(impacting_id impacted_id)],
>>                                TYPE => 'UNIQUE'},
>>         ],
>>     }
>>
>> What do you think about these changes to Schema.pm?  Do you see any 
>> hidden gotcha's here?  I know we're technically frozen for 3.0, 
>> however, there's a business need to get this implemented here and I 
>> wanted to make sure it wasn't going to break anything for 3.2.
>>
>> I'm also looking at possibly implementing this through Hooks, but 
>> wanted to get feedback here first.
>>
>> Kevin
>>
>> -- 
>> -
>> To view or change your list settings, click here:
>> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=after.fallout@gmail.com>
>>   
>


-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kevin.benton.vcf
Type: text/x-vcard
Size: 892 bytes
Desc: not available
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20070109/87aa0531/attachment.vcf>