Opened 4 years ago

Last modified 2 years ago

#17520 assigned Bug

write queries on related managers use the db_for_read database

Reported by: tobias Owned by: slafs
Component: Database layer (models, ORM) Version: 1.3
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

If you execute a write query (update() or delete()) on a queryset obtained from a related manager, it appears to use the db_for_read database instead of the db_for_write database for that query.

The attached patch reproduces the issue on trunk. It also exists in 1.3.1.

Attachments (3)

related_writes_use_write_db.diff (2.4 KB) - added by tobias 4 years ago.
related_writes_use_write_db_v2.diff (2.4 KB) - added by slafs 2 years ago.
slightly modified version for better debugging
related_writes_use_write_db_m2m.diff (4.3 KB) - added by slafs 2 years ago.
test case for a ManyToMany scenario

Download all attachments as: .zip

Change History (11)

Changed 4 years ago by tobias

comment:1 Changed 4 years ago by tobias

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

The issue appears to be that query._db gets set when the queryset is created from a related manager. As such, when the QuerySet.db property checks to see what write db to use, it assumes using() has been called manually and does not call db_for_write on the router as it should.

comment:2 Changed 4 years ago by tobias

  • Patch needs improvement set

The patch only has a test currently (not sure why that got unset, I didn't uncheck anything).

comment:3 Changed 3 years ago by aaugustin

  • Triage Stage changed from Unreviewed to Accepted

Indeed, the test case looks valid and fails.

comment:4 Changed 2 years ago by slafs

  • Owner changed from nobody to slafs
  • Status changed from new to assigned

comment:5 Changed 2 years ago by slafs

The problem seems to be very subtle. The thing is that the update method on queryset is using self.db which uses self._db to determine the database. When we have a related manager, the queryset from it comes with "polluted" _db (because of this ).

When i tried a simplest approach with cleaning the _db after getting the qs like this:

if self._db is None:
    qs._db = None

it turns out that there's some feature tests that gets broken. For example this (which I think isn't documented anywhere). Will try to propose something different.

Changed 2 years ago by slafs

slightly modified version for better debugging

Changed 2 years ago by slafs

test case for a ManyToMany scenario

comment:7 Changed 2 years ago by slafs

  • Patch needs improvement unset

I attached a newer version of tobias patch.

I also added a patch with a test case that shows that the ManyToMany scenario is also broken (you can check it here also)

comment:8 Changed 2 years ago by slafs

  • Patch needs improvement set
Note: See TracTickets for help on using tickets.
Back to Top