Skip to content
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

Refs -- #18597 feat(BaseModelFormSet): Cleanup queryset prep in init and instance fetching #14188

Conversation

agalazis
Copy link

@agalazis agalazis commented Mar 25, 2021

cleanup related to enabling custom prefetched inlines see https://code.djangoproject.com/ticket/18597

@agalazis agalazis force-pushed the feature/18597-code-cleanup-for-custom-prefetched-inline-support branch from e55642e to d5e0433 Compare March 25, 2021 18:46
@agalazis agalazis changed the title 18597 feat(BaseModelFormSet): cleanup queryset prep in init and instance fetching Refs -- #18597 Mar 25, 2021
@agalazis agalazis changed the title Refs -- #18597 Refs -- #18597 feat(BaseModelFormSet): Cleanup queryset prep in init and instance fetching Mar 25, 2021
@agalazis
Copy link
Author

@WhyNotHugo want to have a look?

Copy link
Contributor

@WhyNotHugo WhyNotHugo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense to me. I assume the intent is to follow up with a PR that changes _get_instance_by_queryset_index to use a pre-fetched queryset.

@agalazis
Copy link
Author

agalazis commented Jun 17, 2021

yes but also allow overriding it in general without rewriting a lot of methods(and also not rewriting the whole constructor just to overwrite how queryset is prepared)

@WhyNotHugo
Copy link
Contributor

If the intent is for it to be overridden, then I don't think the name should start with _. This is usually an indicator that it's a private API, not intended to be used by external consumers, nor promising any stability.

@agalazis
Copy link
Author

agalazis commented Jul 16, 2021

I was more interested denote that they are protected and should only be used by subclasses. I was having in mind _ for protected vs __ for private but you know better the coding style of this project and whether it is ok to be entirely public. I will change it this afternoon, thanks.

@agalazis agalazis force-pushed the feature/18597-code-cleanup-for-custom-prefetched-inline-support branch from d5e0433 to 759043f Compare August 4, 2021 09:49
@agalazis
Copy link
Author

agalazis commented Aug 4, 2021

fixed @WhyNotHugo feel free to have a look

@WhyNotHugo
Copy link
Contributor

Everything looks good to me, but I'm not a maintainer.

Maybe mention it here to get more eyes on it?

Copy link
Contributor

@auvipy auvipy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the thing that is missing is adding unit test for the changes

@WhyNotHugo
Copy link
Contributor

This is already covered by tests, the refactor doesn't really add new functionality to test, right?

@felixxm
Copy link
Member

felixxm commented Oct 28, 2021

This is already covered by tests, the refactor doesn't really add new functionality to test, right?

This PR adds new hooks to be overridden by subclasses. We should test if they can be used in the described scenario with prefetch_related(). Moreover new hooks without docs, release notes, and tests are not discoverable, so we would only add them for few folks, which is not our intention.

@WhyNotHugo
Copy link
Contributor

WhyNotHugo commented Oct 28, 2021 via email

@felixxm
Copy link
Member

felixxm commented Nov 18, 2021

@agalazis Do you have time to keep working on this?

@agalazis
Copy link
Author

Yes I ll be back on it within next 2 weeks

@felixxm
Copy link
Member

felixxm commented Jan 17, 2022

Closing due to inactivity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants