-
Notifications
You must be signed in to change notification settings - Fork 84
Fix compatibility with graphql-core v3.2 #83
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
Codecov Report
@@ Coverage Diff @@
## master #83 +/- ##
==========================================
+ Coverage 93.63% 93.71% +0.07%
==========================================
Files 7 7
Lines 330 334 +4
==========================================
+ Hits 309 313 +4
Misses 21 21
Continue to review full report at Codecov.
|
@tfoxy Any movement on this getting merged? |
@sicksid @tfoxy this PR is not working, i have tested it. there is no optimization applied to the queryset |
Notifying @nikolaik of that, too. |
Hi everyone, sorry for not being active here, I took some time out from coding to prioritize other things in my life. I would like to confirm what @hishamkaram said. @nikolaik @sicksid does it optimize the queries for you? Tests are passing fine but they are not integration tests so there may be something wrong where the info being passed in the optimizer is not being actually used now when Django applies the query. |
I have not been using this package in any current project, so haven't been able to prioritise this PR. I initially tried looking at the relevant changes between v3.1 and 3.2 and I believe the two linked commits in the PR description are the relevant ones. @tfoxy Do you understand why my changes are not working? |
I'm not sure right now. I need to read my code again and I will try this PR with a sample app to debug. |
Gave this a go: The PR is good and should be merged. To get around that particular issue, a new converter for ForeignKey/OneToOne fields may be reregistered. But again, this is not a problem related to this PR. You should merge this as is. |
This reverts the change to `convert_field_to_djangomodel` introduced in graphql-python#1315 for the reasons discussed here https://github.com/graphql-python/graphene-django/pull/1315/files#r1015659857. As mentioned there, without reverting this code, "queries are forced every time an object is resolved, making an exponential number of queries when nesting without any possibility of optimizing". That regression prevented `graphene-django-optimizer` from working with `graphene-django` v3.0.0b9+ (where this change first was published), as discussed in graphql-python#1356 (comment), tfoxy/graphene-django-optimizer#86, and tfoxy/graphene-django-optimizer#83 (comment). For now, this marks the two tests that depended on this problematic code as "expected to fail", and perhaps they can be reintroduced if there's a way to support this logic in a way that does not prevent `select_related` and `prefetch_related` query-optimization and introduce nested N+1s. As mentioned here graphql-python#1315 (comment), this is blocking upgrade to graphene-django v3 for many users, and fixing this would allow many to begin upgrading and contributing to keep graphene-django going.
(FYI as to the separate question raised above about failing query-optimization in newer |
This reverts the change to `convert_field_to_djangomodel` introduced in #1315 for the reasons discussed here https://github.com/graphql-python/graphene-django/pull/1315/files#r1015659857. As mentioned there, without reverting this code, "queries are forced every time an object is resolved, making an exponential number of queries when nesting without any possibility of optimizing". That regression prevented `graphene-django-optimizer` from working with `graphene-django` v3.0.0b9+ (where this change first was published), as discussed in #1356 (comment), tfoxy/graphene-django-optimizer#86, and tfoxy/graphene-django-optimizer#83 (comment). For now, this marks the two tests that depended on this problematic code as "expected to fail", and perhaps they can be reintroduced if there's a way to support this logic in a way that does not prevent `select_related` and `prefetch_related` query-optimization and introduce nested N+1s. As mentioned here #1315 (comment), this is blocking upgrade to graphene-django v3 for many users, and fixing this would allow many to begin upgrading and contributing to keep graphene-django going.
Fix is now available in graphene-django v3.0.2. Just a heads up for folks who use get_queryset as an auth layer before this release. If you need that, you can stick with versions between >=3.0.0b9 and <3.1.0 for now. Feel free to suggest a different way that won't lead to those pesky N+1 SQL query issues. |
I have tested this change locally, and it worked seamlessly for my company's project that has quite a bit of
I have tests that check for query optimization/performance as well, and all queries were still optimized. The Would it be possible to merge and publish when you have a chance @tfoxy? Thanks so much! And thank you nikolaik for these fixes! |
Is this good to go using relay? I tried this and the relay query test is still failing. |
@salcedo what are you referring to by "the relay query test is still failing"? CI passed on this branch: https://github.com/tfoxy/graphene-django-optimizer/pull/83/checks. If you're referring to the |
Yes I was unsure if that test being bypassed was a workaround for CI only or if the PR was unfinished. All appears to be working on Django 4.2.1 with Graphene 3.2.2 |
Hi @tfoxy, this PR is coming up on its 1 year mark, and I definitely appreciate that you may not be able to dedicate any further time toward maintaining Thanks again for creating this package and maintaining it for so long! Let me know if there's anything else I or others can do to help. |
This reverts the change to `convert_field_to_djangomodel` introduced in graphql-python#1315 for the reasons discussed here https://github.com/graphql-python/graphene-django/pull/1315/files#r1015659857. As mentioned there, without reverting this code, "queries are forced every time an object is resolved, making an exponential number of queries when nesting without any possibility of optimizing". That regression prevented `graphene-django-optimizer` from working with `graphene-django` v3.0.0b9+ (where this change first was published), as discussed in graphql-python#1356 (comment), tfoxy/graphene-django-optimizer#86, and tfoxy/graphene-django-optimizer#83 (comment). For now, this marks the two tests that depended on this problematic code as "expected to fail", and perhaps they can be reintroduced if there's a way to support this logic in a way that does not prevent `select_related` and `prefetch_related` query-optimization and introduce nested N+1s. As mentioned here graphql-python#1315 (comment), this is blocking upgrade to graphene-django v3 for many users, and fixing this would allow many to begin upgrading and contributing to keep graphene-django going.
Hi everyone! Sorry for not responding for so long. I took some time off from programming for personal reasons. @sjdemartini your comment seems good. I'm going to make you a maintainer of this repo. Not expecting you to do any work here of course, but if it's useful to you then any contributions are welcome. Almost since creating this repo that I'm not working with Python or GraphQL, so it's kind of hard for me to understand the problems people have and how the code fixes them without having any side effects. I'm going to merge this and release a new version since many here already used this PR successfully. |
Please check if it works correctly. Had to upload manually because Travis no longer works. Thanks @nikolaik for taking the time to make the code changes and everyone else for making sure this PR works correctly. @sjdemartini I made you a contributor. Let me know if you need anything else. I will set up GitHub Actions now so that we have testing for PRs and automatic publishing. |
Thanks for taking the time @tfoxy 🤗 |
This reverts the change to `convert_field_to_djangomodel` introduced in graphql-python/graphene-django#1315 for the reasons discussed here https://github.com/graphql-python/graphene-django/pull/1315/files#r1015659857. As mentioned there, without reverting this code, "queries are forced every time an object is resolved, making an exponential number of queries when nesting without any possibility of optimizing". That regression prevented `graphene-django-optimizer` from working with `graphene-django` v3.0.0b9+ (where this change first was published), as discussed in graphql-python/graphene-django#1356 (comment), tfoxy/graphene-django-optimizer#86, and tfoxy/graphene-django-optimizer#83 (comment). For now, this marks the two tests that depended on this problematic code as "expected to fail", and perhaps they can be reintroduced if there's a way to support this logic in a way that does not prevent `select_related` and `prefetch_related` query-optimization and introduce nested N+1s. As mentioned here graphql-python/graphene-django#1315 (comment), this is blocking upgrade to graphene-django v3 for many users, and fixing this would allow many to begin upgrading and contributing to keep graphene-django going.
This reverts the change to `convert_field_to_djangomodel` introduced in graphql-python/graphene-django#1315 for the reasons discussed here https://github.com/graphql-python/graphene-django/pull/1315/files#r1015659857. As mentioned there, without reverting this code, "queries are forced every time an object is resolved, making an exponential number of queries when nesting without any possibility of optimizing". That regression prevented `graphene-django-optimizer` from working with `graphene-django` v3.0.0b9+ (where this change first was published), as discussed in graphql-python/graphene-django#1356 (comment), tfoxy/graphene-django-optimizer#86, and tfoxy/graphene-django-optimizer#83 (comment). For now, this marks the two tests that depended on this problematic code as "expected to fail", and perhaps they can be reintroduced if there's a way to support this logic in a way that does not prevent `select_related` and `prefetch_related` query-optimization and introduce nested N+1s. As mentioned here graphql-python/graphene-django#1315 (comment), this is blocking upgrade to graphene-django v3 for many users, and fixing this would allow many to begin upgrading and contributing to keep graphene-django going.
This reverts the change to `convert_field_to_djangomodel` introduced in graphql-python/graphene-django#1315 for the reasons discussed here https://github.com/graphql-python/graphene-django/pull/1315/files#r1015659857. As mentioned there, without reverting this code, "queries are forced every time an object is resolved, making an exponential number of queries when nesting without any possibility of optimizing". That regression prevented `graphene-django-optimizer` from working with `graphene-django` v3.0.0b9+ (where this change first was published), as discussed in graphql-python/graphene-django#1356 (comment), tfoxy/graphene-django-optimizer#86, and tfoxy/graphene-django-optimizer#83 (comment). For now, this marks the two tests that depended on this problematic code as "expected to fail", and perhaps they can be reintroduced if there's a way to support this logic in a way that does not prevent `select_related` and `prefetch_related` query-optimization and introduce nested N+1s. As mentioned here graphql-python/graphene-django#1315 (comment), this is blocking upgrade to graphene-django v3 for many users, and fixing this would allow many to begin upgrading and contributing to keep graphene-django going.
This reverts the change to `convert_field_to_djangomodel` introduced in graphql-python/graphene-django#1315 for the reasons discussed here https://github.com/graphql-python/graphene-django/pull/1315/files#r1015659857. As mentioned there, without reverting this code, "queries are forced every time an object is resolved, making an exponential number of queries when nesting without any possibility of optimizing". That regression prevented `graphene-django-optimizer` from working with `graphene-django` v3.0.0b9+ (where this change first was published), as discussed in graphql-python/graphene-django#1356 (comment), tfoxy/graphene-django-optimizer#86, and tfoxy/graphene-django-optimizer#83 (comment). For now, this marks the two tests that depended on this problematic code as "expected to fail", and perhaps they can be reintroduced if there's a way to support this logic in a way that does not prevent `select_related` and `prefetch_related` query-optimization and introduce nested N+1s. As mentioned here graphql-python/graphene-django#1315 (comment), this is blocking upgrade to graphene-django v3 for many users, and fixing this would allow many to begin upgrading and contributing to keep graphene-django going.
This fixes the compatibility issues with graphql-core v3.2.
The relevant changes in graphql-core are these two commits:
Fixes #82
There was a failing relay test which I couldn't find any solution for, so I made a workaround in 5a6791d. Do you have an idea what could be wrong?
Also the promise library was failing to install on python 3.7 so I bumped the python patch version which includes a newer setuptools I believe