From 9595183d03cfd0d94ae2dd506a3d2b86cf5c74a7 Mon Sep 17 00:00:00 2001 From: Russell Keith-Magee Date: Mon, 30 Sep 2013 13:05:43 +0800 Subject: Fixed #13724: Corrected routing of write queries involving managers. Previously, if a database request spanned a related object manager, the first manager encountered would cause a request to the router, and this would bind all subsequent queries to the same database returned by the router. Unfortunately, the first router query would be performed using a read request to the router, resulting in bad routing information being used if the subsequent query was actually a write. This change defers the call to the router until the final query is acutally made. It includes a small *BACKWARDS INCOMPATIBILITY* on an edge case - see the release notes for details. Thanks to Paul Collins (@paulcollinsiii) for the excellent debugging work and patch. --- docs/releases/1.7.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'docs') diff --git a/docs/releases/1.7.txt b/docs/releases/1.7.txt index 573ad49dc2..74fc74947c 100644 --- a/docs/releases/1.7.txt +++ b/docs/releases/1.7.txt @@ -368,6 +368,20 @@ For apps with migrations, ``allow_migrate`` will now get passed without custom attributes, methods or managers. Make sure your ``allow_migrate`` methods are only referring to fields or other items in ``model._meta``. +Passing ``None`` to ``Manager.db_manager()`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In previous versions of Django, it was possible to use +``db_manager(using=None)`` on a model manager instance to obtain a manager +instance using default routing behavior, overriding any manually specified +database routing. In Django 1.7, a value of ``None`` passed to db_manager will +produce a router that *retains* any manually assigned database routing -- the +manager will *not* be reset. This was necessary to resolve an inconsistency in +the way routing information cascaded over joins. See `Ticket #13724`_ for more +details. + +.. _Ticket #13724: https://code.djangoproject.com/ticket/13724 + pytz may be required ~~~~~~~~~~~~~~~~~~~~ -- cgit v1.3