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

Django core integration #23

Open
browze opened this issue Apr 20, 2023 · 2 comments
Open

Django core integration #23

browze opened this issue Apr 20, 2023 · 2 comments

Comments

@browze
Copy link

browze commented Apr 20, 2023

This lib looks like it would be extremely useful to include in the main Django framework. As far as I can tell from the README it doesn't imply any breaking changes either.

I wonder if you could comment on whether you've reached out to django core or have any kind of open issue or pull request on it that I could follow? Has any core maintainer already indicated their attitude to incorporating this sort of functionality? A brief search on the core django repo didn't show anything but maybe I'm overlooking it.

Thanks!

@AlexHill
Copy link
Owner

AlexHill commented Apr 27, 2023

Hi @browze, thanks for your thoughts.

I did at one point post this project to the django-developers mailing list with the aim of integrating it into Django. Simon Charette expressed interest but the discussion fizzled out (my fault). However in a DjangoCon talk by Simon late last year he mentioned this project in the context of discussing functionality that was missing from the ORM. So it sounds like there is still some appetite there.

As you say, there are no breaking changes here - there's a bit of backwards-compatible monkeypatching and some contortions of the ORM internals to make them do what we want, but as long as the tests pass that's OK! If this functionality were to be integrated into the ORM it would make sense to change some of those ORM internals to be a bit friendlier.

@browze
Copy link
Author

browze commented May 3, 2023

Thanks for the info @AlexHill - I'll check that talk out. Might be worth sending them a nudge? I think it will definitely make the ORM more comprehensive and it's reasonable to support giving users control of joins for prefetching etc. I can understand 'encouraging' people to use standard FKs wherever possible - but I think most people will anyway - and a note in the docs + the requirement for extra args/kwargs when joining on non FK fields would hopefully suffice to ensure the vast majority use FKs where they reasonably can.

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

No branches or pull requests

2 participants