Impact Table Implementation

[Bill Barry]

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"
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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20070109/e4a2bb4f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1784 bytes
Desc: not available
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20070109/e4a2bb4f/attachment.png>