[Django] #29762: Explicit 'Using' with foreign Key on model
Django
-------------------------------------+-------------------------------------
Reporter: Vackar | Owner: nobody
Afzal |
Type: | Status: new
Uncategorized |
Component: Database | Version: 2.0
layer (models, ORM) |
Severity: Normal | Keywords: oracle, multidb
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29762>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: closed
Component: Database layer | Version: 2.0
(models, ORM) |
Severity: Normal | Resolution: needsinfo
Keywords: oracle, multidb | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* type: Uncategorized => Bug
* resolution: => needsinfo
Comment:
The behavior you describe shouldn't happen.
[https://github.com/django/django/blob/da92ec79621fc0bba671d8afa52b7f6884962fe5/tests/multiple_database/tests.py#L444-L448
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29762#comment:1>
Django
-------------------------------------+-------------------------------------
Component: Database layer | Version: 2.0
(models, ORM) |
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: closed => new
* resolution: needsinfo =>
Comment:
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?
--
Ticket URL: <https://code.djangoproject.com/ticket/29762#comment:2>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Component: Database layer | Version: 2.0
(models, ORM) |
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (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?
--
Ticket URL: <https://code.djangoproject.com/ticket/29762#comment:3>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Component: Database layer | Version: 2.0
(models, ORM) |
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (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'
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/29762#comment:4>
Django
-------------------------------------+-------------------------------------
Reporter: Vackar Afzal | Owner: nobody
Cleanup/optimization |
Component: Documentation | Version: 2.0
Severity: Normal | Resolution:
Keywords: oracle, multidb | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* type: Bug => Cleanup/optimization
* component: Database layer (models, ORM) => Documentation
Comment:
Right, so you're overriding
[https://github.com/django/django/blob/f5e347a6402c1996a8f7063de4b314bae4a55683/django/db/utils.py#L262-L263
the default behavior] of using the database from which the object was
fetched.
--
Ticket URL: <https://code.djangoproject.com/ticket/29762#comment:5>
Django
Reporter: Vackar Afzal | Owner: nobody
Component: Documentation | Version: 2.0
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/29762#comment:6>
Django
--------------------------------------+------------------------------------
Reporter: Vackar Afzal | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 2.0
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Vackar Afzal):
Yes, that's correct - thanks for your help in resolving this issue.
--
Ticket URL: <https://code.djangoproject.com/ticket/29762#comment:7>
Django
--------------------------------------+------------------------------------
Reporter: Vackar Afzal | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 2.0
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Ülgen Sarıkavak):
* cc: Ülgen Sarıkavak (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/29762#comment:8>
Django
--------------------------------------+------------------------------------
Reporter: Vackar Afzal | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 2.0
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29762#comment:9>
Django
--------------------------------------+------------------------------------
Reporter: Vackar Afzal | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 2.0
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by VIZZARD-X):
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/29762#comment:10>
Django
--------------------------------------+------------------------------------
Reporter: Vackar Afzal | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 2.0
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by VIZZARD-X):
Recreated my fork and restored the branch. New PR:
https://github.com/django/django/pull/20310
Patch content remains valid and unchanged.
--
Ticket URL: <https://code.djangoproject.com/ticket/29762#comment:11>