Re-design Package to Vulnerability model relationships

[pombredanne]

The current models is that a Package is related to Vulnerability through a generic PackageRelatedVulnerability relationship with a fix attribute

• https://github.com/nexB/vulnerablecode/blob/40a39743f385bd5b6dfa3424bc72231fe1ae7456/vulnerabilities/models.py#L491

• https://github.com/nexB/vulnerablecode/blob/40a39743f385bd5b6dfa3424bc72231fe1ae7456/vulnerabilities/models.py#L584

• https://github.com/nexB/vulnerablecode/blob/40a39743f385bd5b6dfa3424bc72231fe1ae7456/vulnerabilities/models.py#L614

This approach is problematic and not obvious. It makes queries more complex and slower.

We should instead evolve the models towards separate AffectedPackages and FixingPackage or something along these lines to be designed.

See these related issues:

• Change resolved_to to fixed_by in Models #715
• Make models better for efficient queries #966
• AffectedPackage as model #727
• The query for affected and fixed packages should be abstracted as methods on the models (and/or on a model manager) #595

[Hritik14]

@pombredanne

It makes queries more complex

We could possibly avoid that by some abstraction as proposed in #595

and slower

Slower than ... ?

[Hritik14]

As per discussion during call:

A fix is more complex than just a package. It can be much more than that. Fixes can come in terms of fix commits, individual patches etc
@pombredanne

[TG1999]

@pombredanne I am closing this issue, since we have 2 models for storing PackageVulnerability relationship. Feel free to re-open if needed, This has been merged with:

• Segregate PackageRelatedVulnerability model to new models #1612