Opened 2 years ago

Last modified 2 years ago

#29762 new Cleanup/optimization

Document how database routers are used for related object access

Reported by: Vackar Afzal Owned by: nobody
Component: Documentation Version: 2.0
Severity: Normal Keywords: oracle, multidb
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Change History (7)

comment:1 Changed 2 years ago by Tim Graham

Resolution: needsinfo
Status: newclosed
Type: UncategorizedBug

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.

comment:2 Changed 2 years ago by Vackar Afzal

Resolution: needsinfo
Status: closednew

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?

comment:3 Changed 2 years ago by 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?

comment:4 Changed 2 years ago by 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'

comment:5 Changed 2 years ago by Tim Graham

Component: Database layer (models, ORM)Documentation
Summary: Explicit 'Using' with foreign Key on modelDocument how database routers are used for related object access
Type: BugCleanup/optimization

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

comment:6 Changed 2 years ago by Tim Graham

Triage Stage: UnreviewedAccepted

comment:7 Changed 2 years ago by Vackar Afzal

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

Note: See TracTickets for help on using tickets.
Back to Top