Check dependent libraries: https://github.com/tfoxy/graphene-django-optimizer and https://github.com/eamigo86/graphene-django-extras #1356
Labels
Comments
|
@firaskafri Thanks so much for your work to officially release v3.0.0 and revive this project! It turns out the v3.0.0 release unfortunately does not work with I'm not familiar enough with the internals of |
sjdemartini
added a commit
to sjdemartini/graphene-django
that referenced
this issue
Apr 29, 2023
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.
|
@firaskafri Thanks again for all your work toward keeping this project alive. I saw you just released a new 3.0.1 version today! 🎉 I tried that version with I investigated in more detail to see if I could help, and I came across the discussion here #1315 (comment). I tested reverting that change and indeed it did fix the query-optimization, so I've opened a PR to revert the problematic code #1401, which I believe is the right move at least until a more query-friendly approach could be implemented for it later. Thank you for considering, hopeful to upgrade and continue using |
firaskafri
pushed a commit
that referenced
this issue
May 3, 2023
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.
|
graphene-django-optimizer support was fixed as of the above PR #1401 (published in 3.0.2), and graphene-django-extras added official graphene v3 support (non-beta) in its 1.0.0 version eamigo86/graphene-django-extras#191, so closing this out! 🙌 |
igodev0001
pushed a commit
to igodev0001/graphene-django
that referenced
this issue
Jul 4, 2023
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.
superlevure
pushed a commit
to loft-orbital/graphene-django
that referenced
this issue
Jul 19, 2023
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.
DevStar1016
added a commit
to DevStar1016/graphine-django
that referenced
this issue
Sep 11, 2023
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.
Yaroslav-Dev007
added a commit
to Yaroslav-Dev007/graphene-django
that referenced
this issue
Feb 9, 2025
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.
BohdanS000
added a commit
to BohdanS000/python-django-graphql
that referenced
this issue
Feb 15, 2025
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.
light0725
added a commit
to light0725/graphene-django
that referenced
this issue
Mar 5, 2025
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Check dependent libraries: https://github.com/tfoxy/graphene-django-optimizer and https://github.com/eamigo86/graphene-django-extras
The text was updated successfully, but these errors were encountered: