#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 django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.8a443531f073dc09498c9a987b387c00%40djangoproject.com.
