Opened 9 years ago

Closed 5 years ago

#13663 closed New feature (wontfix)

Foreign Key to table in another database fails

Reported by: berto Owned by: nobody
Component: Database layer (models, ORM) Version: 1.2
Severity: Normal Keywords:
Cc: Triage Stage: Someday/Maybe
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


I'm working with a legacy database that references records in another database by ID. I would like to use Django's ForeignKey field to access this data. Out of the box, this fails with the error below. When using ForeignKey, the query is bound to using the same db as the current model. I'm not sure if it's the right thing to do, but the problem is solved by removing using() from the query in django/db/models/fields/ on line 302.

I think being able to use Django's ForeignKey and friends across databases would be quite useful, albeit not being able to set database-level contraints on the relations.


DatabaseError                             Traceback (most recent call last)

/Users/berto/repo/webapp/<ipython console> in <module>()

/Users/berto/local/opt/django/current/django/db/models/fields/ in __get__(self, instance, instance_type)
    300                 rel_obj = rel_mgr.using(db).get(**params)
    301             else:
--> 302                 rel_obj = QuerySet(**params)
    303             setattr(instance, cache_name, rel_obj)
    304             return rel_obj

/Users/berto/local/opt/django/current/django/db/models/query.pyc in get(self, *args, **kwargs)
    334         if self.query.can_filter():
    335             clone = clone.order_by()
--> 336         num = len(clone)
    337         if num == 1:
    338             return clone._result_cache[0]

/Users/berto/local/opt/django/current/django/db/models/query.pyc in __len__(self)
     79                 self._result_cache = list(self._iter)
     80             else:
---> 81                 self._result_cache = list(self.iterator())
     82         elif self._iter:
     83             self._result_cache.extend(list(self._iter))

/Users/berto/local/opt/django/current/django/db/models/query.pyc in iterator(self)
    268         compiler = self.query.get_compiler(using=self.db)
--> 269         for row in compiler.results_iter():
    270             if fill_cache:
    271                 obj, _ = get_cached_row(self.model, row,

/Users/berto/local/opt/django/current/django/db/models/sql/compiler.pyc in results_iter(self)
    670         resolve_columns = hasattr(self, 'resolve_columns')
    671         fields = None
--> 672         for rows in self.execute_sql(MULTI):
    673             for row in rows:
    674                 if resolve_columns:

/Users/berto/local/opt/django/current/django/db/models/sql/compiler.pyc in execute_sql(self, result_type)
    726         cursor = self.connection.cursor()
--> 727         cursor.execute(sql, params)
    729         if not result_type:

/Users/berto/local/opt/django/current/django/db/backends/util.pyc in execute(self, sql, params)
     13         start = time()
     14         try:
---> 15             return self.cursor.execute(sql, params)
     16         finally:
     17             stop = time()

/Users/berto/local/opt/django/current/django/db/backends/postgresql_psycopg2/base.pyc in execute(self, query, args)
     42     def execute(self, query, args=None):
     43         try:
---> 44             return self.cursor.execute(query, args)
     45         except Database.IntegrityError, e:
     46             raise utils.IntegrityError, utils.IntegrityError(*tuple(e)), sys.exc_info()[2]

DatabaseError: current transaction is aborted, commands ignored until end of transaction block

Change History (7)

comment:1 Changed 9 years ago by Tryphon

Component: UncategorizedDatabase layer (models, ORM)

comment:2 Changed 9 years ago by Russell Keith-Magee

Triage Stage: UnreviewedSomeday/Maybe

ForeignKeys between databases doesn't work, and is documented to not work; it's also non-trivial to fix while retaining referential integrity. It certainly isn't as simple as dropping a using clause. Marking someday/maybe as a general placeholder for the fact that this would be nice to have.

comment:3 Changed 8 years ago by Julien Phalip

Severity: Normal
Type: New feature

comment:4 Changed 7 years ago by Aymeric Augustin

UI/UX: unset

Change UI/UX from NULL to False.

comment:5 Changed 7 years ago by Aymeric Augustin

Easy pickings: unset

Change Easy pickings from NULL to False.

comment:6 Changed 7 years ago by Aymeric Augustin

I'm not sure we want to go down this rabbit hole. I think it's safer to insist that ForeignKey don't work across databases, and force users to do queries in different databases manually (NoSQL style).

comment:7 Changed 5 years ago by Aymeric Augustin

Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.
Back to Top