-
Notifications
You must be signed in to change notification settings - Fork 201
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
Backend: Fix duplicate reference urls(#343) #408
Conversation
Signed-off-by: savish <[email protected]>
@sbs2001 ping. Could you please review the PR. |
@savish28 I'm not really sure how much of impact this is going to have on the db side things, since we are doing more queries per So here's what I suggest. Keep the url normalization part in the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@savish28 as mentioned in the comment, keep the url normalization in the save method.
Move scheme inference thing t management command
vulnerabilities/models.py
Outdated
@@ -110,6 +111,38 @@ class VulnerabilityReference(models.Model): | |||
def scores(self): | |||
return VulnerabilitySeverity.objects.filter(reference=self.id) | |||
|
|||
def save(self, *args, **kwargs): | |||
if self.id: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean any update would go through straight ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sbs2001 Yes. Because whenever we add a new object we might need to update a previously saved object and if we don't do this it might go into an infinite loop.
url_parsed = urlpy.parse(self.url) | ||
self.url = str(url_parsed.canonical()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this handle the case where self.url=None
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or self.url=""
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated the code. It returned "/" for the same but keeping "" for "" would make more sense so updated the changes.
self.url = str(url_parsed.canonical()) | ||
url_scheme = url_parsed.scheme | ||
scheme_independent_url = self.url[len(url_scheme) :] | ||
if url_scheme == "http": |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This block should be broken down into a separate function.
).first() | ||
if not similar_instance: | ||
super(VulnerabilityReference, self).save(*args, **kwargs) | ||
elif url_scheme == "https": |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above, This block should be broken down into a separate function.
).first() | ||
if similar_instance: | ||
similar_instance.url = self.url | ||
similar_instance.save() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
return similar_instance.save()
would be better here for readability
similar_instance.url = self.url | ||
similar_instance.save() | ||
else: | ||
super(VulnerabilityReference, self).save(*args, **kwargs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use a return
here
else: | ||
super(VulnerabilityReference, self).save(*args, **kwargs) | ||
else: | ||
super(VulnerabilityReference, self).save(*args, **kwargs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above, for the computers it doesn't make difference, but when reading I don't have to verify whether the return value is correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@savish28 I'm not really sure how much of impact this is going to have on the db side things, since we are doing more queries per
save
. The imports are already slow enough.So here's what I suggest. Keep the url normalization part in the
save
method. The scheme thing, should be moved into a separate job/command, https://docs.djangoproject.com/en/3.1/howto/custom-management-commands/ .
@sbs2001 So, a nice idea, Does this mean that the command/job python manage.py job_name
have to be called explicitly by the admin to run the following job and it would go through all the entries and it would update the db. I think it can be extended in two ways:-
- If no arguments are passed then all the entries are looked upon and are checked.
- If arguments like id/Vulnerability/source etc are passed and only filtered objects are processed.
I think that in this case, each run would cost O(N) queries and would not be automated.
But in the save method update, it would cost 1 extra query per update and would be automated. So I think query wise the override save method is more time-efficient and more automated.
What would be your suggestion in the case and if we are going with the job idea, does the proposed method would work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
called explicitly by the admin
We could get clever by running the job after each import, so this is a non-issue, I guess.
- If no arguments are passed then all the entries are looked upon and are checked.
- If arguments like id/Vulnerability/source etc are passed and only filtered objects are processed.
Btw I want to remove the source thing when I get time :) it's not populated anywhere and is a bad way to keep track of source(s) . With that out of the way, what would be the use case of (2) ? In almost all cases (1) would be used.
each run would cost O(N) queries
IMHO that can be done 1 + (no of duplicates)
. One query to fetch all references (just the id and url columns) . Iterate over all records from server side, check for dups in the already fetched records. If a dup is found follow the procedure along the lines of what you're doing here, so that's gonna cost 1 DELETE
query per dup.
Dups are rare anyways so it won't be O(N) .
it would cost 1 extra query per update
IMHO that'd be 1 extra query per insert/ (save
method invocation in most cases )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohh okay, I get the idea. We are importing all the data and then doing this job. This would result in more efficiency rather than doing operation at each save.
So I guess these are the deliverables now,
- Create Job for removing duplicates.
- Add functionality to run the job after each import.
Does this seem right? @sbs2001
Signed-off-by: savish <[email protected]>
@savish28 I just realized there's a third way to do this which would be even better. Let's move your logic in a wrapper method like So as far as queries are concerned |
@savish28 ping :) |
@savish28 gentle ping. |
@savish28 do you think you want to complete and bring this to a mergeable state? |
@pombredanne Sure, closing this PR for now. |
Fix: #343.
The following changes are been proposed in this PR: