-
Notifications
You must be signed in to change notification settings - Fork 120
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
Add support for adding pull-through content to associated repositories #6224
base: main
Are you sure you want to change the base?
Conversation
pulpcore/content/handler.py
Outdated
except IntegrityError: | ||
# Remote artifact must have already been saved during a parallel request | ||
log.info(f"RemoteArtifact for {url} already exists.") | ||
if ca.relative_path == content_artifact.relative_path: | ||
# Side effect used by pull-through-caching in _stream_remote_artifact | ||
remote_artifact.content_artifact = ca |
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.
Apart from the question, why we should rename the variable in the first place, does remote_artifact
exist here?
Also should we save "content_artifact" on the model when we set it? Maybe the comment is missing some nasty details to understand the codeflow here.
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.
remote_artifact
exists in the method definition.
I don't understand your second question, but I am wondering if I even need to use a side-effect to get the newly saved content_artifact for the pull-through method. This is a private method and searching through the code-base no one uses this method besides the content app, so maybe I can just change the return type to a dictionary of all the newly created objects.
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.
So content_artifact isn't even a field on the remote_artifact?
But yes the returning the proper stuff sounds better.
So sad that with python it's usually hard to guess what is a private and what a public interface...
57606c3
to
3118fc1
Compare
@middleware | ||
async def guid(request, handler): | ||
"""Sets the django_guid for each request.""" | ||
set_guid(generate_guid()) | ||
return await handler(request) | ||
|
||
|
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 sounds like a good change in general. Maybe that's a different story, but should we look for the cid header in the request to allow following correlations even through content access?
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.
Maybe yeah, we would also need to expose the value to be used in logging for the content app, currently this change is solely to allow for dispatching tasks from the content app.
3118fc1
to
1c41bb0
Compare
No description provided.