#32632: Query resolution can be at least 3x slower in 3.2
-------------------------------------+-------------------------------------
Reporter: Phillip Cutter | Owner: Simon
| Charette
Type: Bug | Status: assigned
Component: Database layer | Version: 3.2
(models, ORM) |
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Simon Charette):
* has_patch: 0 => 1
Comment:
> 2 & 3 make sense for me, however I would like to see an implementation
first. This can be too massive for backporting. I'm a bit afraid that we
can open the Pandora's box.
Hopefully the proposed patch is not too invasive, I could try to figure
out another approach. From an invasivity reduction perspective removing
the `Node.add` branch seems like a clear choice for this particular issue
but I wouldn't be surprised if other code paths were affected by the
slowness introduced by `sql.Query.__eq__`.
> Will we be able to keep support for combining Q() objects ​with boolean
expressions?
Yep, it shouldn't be an issue. The main change is really that `Subquery`
doesn't partially implement the deconstruct API which is only really
useful for migrations anyway.
--
Ticket URL: <https://code.djangoproject.com/ticket/32632#comment:6>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.8a443531f073dc09498c9a987b387c00%40djangoproject.com.
