-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
Search: refactor serializer's context #9624
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
Conversation
@@ -132,8 +110,7 @@ def get(self, request, project_slug): | |||
use_advanced_query=use_advanced_query, | |||
) | |||
|
|||
context = self.get_serializer_context(project_obj, user_input.version) |
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.
Passing the context here was saving just one query, and to pass it again we will need to query the version (we have only the slug), so we are just omitting the projects
parameter here for now (we would use it again when using the new search)
We were generating the context of the serializer from outside, but we can do this from the serializer itself, this way we don't have to duplicate this logic.
e84b905
to
e145700
Compare
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.
I'm not 100% sure to understand the benefits of it but I don't see anything wrong, tho. So, I think we are fine moving forward with this PR since I assume it will make the new API simpler.
if projects: | ||
context = kwargs.setdefault("context", {}) | ||
context["projects_data"] = { | ||
project.slug: self._build_project_data(project, version.slug) |
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.
I think it's better if we pass the project
and the version
object, in particular if it's a private method and won't be used from outside. Then we can consume whatever is required from the inner method.
The API is easier to use and it's easier to think about while following the code, IMO.
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.
In fact, the similar version of this method (_get_project_data
) was receiving the objects as I'm suggesting 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.
Oh, now I remember why this was changed, I was about to use it in this same class, to avoid duplicating the logic at
readthedocs.org/readthedocs/search/api/v2/serializers.py
Lines 117 to 132 in 2858e6e
if project: | |
docs_url = project.get_docs_url(version_slug=obj.version) | |
project_alias = project.superprojects.values_list( | |
"alias", flat=True | |
).first() | |
projects_data = self.context.setdefault("projects_data", {}) | |
version_data = VersionData( | |
slug=obj.version, | |
docs_url=docs_url, | |
) | |
projects_data[obj.project] = ProjectData( | |
alias=project_alias, | |
version=version_data, | |
) | |
return projects_data[obj.project] |
We were generating the context of the serializer
from outside, but we can do this from
the serializer itself,
this way we don't have to duplicate this logic.
We have been calling this "projects", but it's a combination of project and version (tuple), not sure about a better name for this.
This is on top of #9616
📚 Documentation previews 📚
docs
): https://docs--9624.org.readthedocs.build/en/9624/dev
): https://dev--9624.org.readthedocs.build/en/9624/