Document how database routers are used for related object access

[Vackar Afzal]

When run a filter query like this:

my_instance = MyModel.objects.using('NonDefaultDBConn').filter(some_field='XXXX')
my_instance.local_field  #This works
my_instance.fk_field     #This doesn't work

It fails when trying to access my_instance.fk_field as it defaults to using the 'default' connection and not 'NonDefaultDBConn'

I would assume that when fetching a model using 'NonDefaultDBConn' that all subsequent lookups should go through 'NonDefaultDBConn' and not 'default'

If this is not the case, and this is expected behaviour how can I force fk lookups to go through 'NonDefaultDBConn'

I know I can run

MyLinkedModel.objects.filter(x_instance=my_instance)

But this is massively in-efficient both from a performance and code maintainability point of view.

I am using Django 2.0 with the Oracle backend.

[Tim Graham]

The behavior you describe shouldn't happen. ​There are tests in Django's test suite that demonstrates. I also tried this:

dive = Book.objects.using('other').filter(title="Dive into Python")[0]
self.assertEqual(dive.editor.name, "Chris Mills")

Please provide a test case or a sample project that reproduces the problem you're seeing.

[Vackar Afzal]

Apologies I should have been clearer with the problem, it's similar to what is being described here:
​https://stackoverflow.com/questions/40457351/why-is-the-database-used-by-django-subqueries-not-sticky

My application has a single 'MetaSchema' and 'n' identical ApplicationSchemas.
The default connection points to the meta-schema, and the default router routes everything via 'defaut'

AppModel1 is not present in the default 'MetaSchema', but is present in all of the ApplicationSchemas

Running this fails on the second line:

obj =  AppModel1.objects.using('ApplicationSchema1').first()
obj.objects.fk_field # <--- This fails

However, looking at the router configuration for the tests, I think it may be a misconfiguration issue on my part. It looks like I need to setup the router as follows:

class TestRouter:
 
    def db_for_read(self, model, instance=None, **hints):
        if instance:
            return instance._state.db or 'default'
        return 'default'

       .....

Is this something worth mentioning / or highlighting in the Documentation?

[Tim Graham]

The test router isn't used for the test that I linked to. I also tried this and it works fine in the test:

dive = Book.objects.using('other').first() 
self.assertEqual(dive.editor.name, "Chris Mills")

Are you using a database router in your project?

[Vackar Afzal]

I am indeed, and that's probably what's causing the odd behaviour:

class MyRouter(object):

    def db_for_read(self, model, **hints):
        return 'default'

    def db_for_write(self, model, **hints):
        return 'default'

    def allow_relation(self, obj1, obj2, **hints):
       return True

    def allow_migrate(self, db, app_label, model_name=None, **hints):
        return db == 'default'

[Tim Graham]

Right, so you're overriding ​the default behavior of using the database from which the object was fetched.

[Vackar Afzal]

Yes, that's correct - thanks for your help in resolving this issue.

[VIZZARD-X]

Submitted a PR for this issue: ​https://github.com/django/django/pull/20292

This documents how related-object database selection works in multi-database
configurations, including the use of instance._state.db and the instance
hint passed to db_for_read() in routers.

[VIZZARD-X]

Recreated my fork and restored the branch. New PR:

​https://github.com/django/django/pull/20310

Patch content remains valid and unchanged.

[Vijaya Lakshmi Pokala]

Hi, I’d like to work on this ticket and submit a patch soon.

[Nabeel]

I have opened a pull request for this documentation clarification.

PR: ​https://github.com/django/django/pull/20841/commits

[blighj]

I've reviewed the additional wording, it covers the topic of this ticket, it is relatively concise, and been through a couple of edits. I marking this ready for checkin.

[Jacob Walls <jacobtylerwalls@…>]

In edd8997:

Fixed #29762 -- Doc'd how database routers fetch related objects.

Thanks James Bligh for the review.

Co-authored-by: Jacob Walls <jacobtylerwalls@…>

[Jacob Walls <jacobtylerwalls@…>]

In 00f0b0d2:

[6.0.x] Fixed #29762 -- Doc'd how database routers fetch related objects.

Thanks James Bligh for the review.

Co-authored-by: Jacob Walls <jacobtylerwalls@…>

Backport of edd899786851f6285abbc3c272f4f5ec0e48a74c from main.