-
Notifications
You must be signed in to change notification settings - Fork 226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-design Package to Vulnerability model relationships #1068
Comments
We could possibly avoid that by some abstraction as proposed in #595
Slower than ... ? |
As per discussion during call:
|
@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: |
The current models is that a
Package
is related toVulnerability
through a genericPackageRelatedVulnerability
relationship with afix
attributehttps://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:
AffectedPackage
as model #727The text was updated successfully, but these errors were encountered: