Generic Foreign Keys break when used with multi-db.

[legutierr]

Specifically, retrieving and saving objects that use the GenericForeignKey descriptor fails when the ContentType table is stored in a different database than the table of the instance being retrieved or saved.

There can only be one valid and consistent content-type table in a system. In a two-db system, the content type table will be in either db A or db B. Therefore, a portion of the system's tables will be registered in a content-type table that is stored in a different database.

This is all OK when retrieving objects based on a GenericForeignKey reference, because a user in such a situation will typically rely on the underlying routers to determine which database to use in retrieving content-type records.

However, this method in ​django/trunk/django/contrib/contenttypes/generic.py does not use routers in determining what database to use to fetch the content-type, but instead uses the source database of the orm object the content-type of which is being queried:

52	    def get_content_type(self, obj=None, id=None, using=None):
53	        # Convenience function using get_model avoids a circular import when
54	        # using this model
55	        ContentType = get_model("contenttypes", "contenttype")
56	        if obj:
57	             return ContentType.objects.db_manager(obj._state.db).get_for_model(obj)
58	        elif id:
59	             return ContentType.objects.db_manager(using).get_for_id(id)
60	        else:
61	            # This should never happen. I love comments like this, don't you?
62	            raise Exception("Impossible arguments to GFK.get_content_type!")

The above method is what is used at object-creation time to transform a generic object in the __init__ kwargs of a new orm object into a content-type/object-id pair for purposes of saving. The use of this method results in either: (a) an error being generated when the specified table is not to be found in the designated database; or (b) incorrect information being saved when a parallel--but incorrect (according to the router rules)--content type table from the other database is used (i.e. database corruption).

A simple fix would be to not assume that the content-types table is in the same database as the object with the GenericForeignKey field. I don't have a patch right now, but it may be as simple as replacing line 57:

57	             return ContentType.objects.db_manager(obj._state.db).get_for_model(obj)

with:

57	             return ContentType.objects.db_manager(using).get_for_model(obj)

A similar error seems to exist in the following block of code as well, however:

220	        manager = RelatedManager(
221	            model = rel_model,
222	            instance = instance,
223	            symmetrical = (self.field.rel.symmetrical and instance.__class__ == rel_model),
224	            join_table = qn(self.field.m2m_db_table()),
225	            source_col_name = qn(self.field.m2m_column_name()),
226	            target_col_name = qn(self.field.m2m_reverse_name()),
227	            content_type = ContentType.objects.db_manager(instance._state.db).get_for_model(instance),
228	            content_type_field_name = self.field.content_type_field_name,
229	            object_id_field_name = self.field.object_id_field_name
230	        )

Requiring that line 227 be replaced, perhaps:

227	            content_type = ContentType.objects.get_for_model(instance),

The problem here is that no using argument is specified for the __get__ method, nor can a using argument be specified there, making the usage in that function inconsistent with the rest of the file, should this fix be put in place.

[Russell Keith-Magee]

This isn't a minor problem to fix, but it's definitely a problem.

[natalie.stepina@…]

Django 1.2.1 patch for ContentType multi-db support

[natalie.stepina@…]

See attached django_contenttypes.patch. Worked for us on Django 1.2.1.

[Aymeric Augustin]

Since this is obviously a problem, I'm marking the ticket as accepted.

[Eric Simorre]

see similar ticket #19068

[4glitch@…]

This works for me on 1.5.1

[Joe <jac@…>]

4glitch, I think your patch would also need to address ContentType.get_all_objects_for_this_type(). Applying the same fix that you used for ContentType.get_object_for_this_type() seems to work for me, i.e.:

Old:

173        return self.model_class()._base_manager.using(self._state.db).filter(**kwargs)

New:

173        return self.model_class()._base_manager.using(router.db_for_read
(self.model_class()) or DEFAULT_DB_ALIAS).filter(**kwargs)

That said, I haven't tested your patch or this proposed modification thoroughly yet.

[4glitch@…]

The same approach for 1.6.5

[Claude Paroz]

Thanks, but tests are still missing...

[socketubs]

If I understand correctly why these patches are not applied, it's just because tests are missing ?
I can help for writing tests but I have never contributed to Django...

[Tim Graham]

We have ​a lot of documentation with tips for new contributors. You may find the ​patch review checklist particularly helpful.

[Dmitri Bogomolov <4glitch@…>]

I cannot reproduce this issue on two sqlite databases (test_sqlite). Probably need another backend.

[Tim Graham]

Might be a duplicate of #16281 as the patch proposed there also modifies these methods.

[bcail]

The GenericForeignKey docs (​https://docs.djangoproject.com/en/5.0/ref/contrib/contenttypes/#django.contrib.contenttypes.fields.GenericForeignKey) talk about having a ForeignKey to ContentType. Would that ForeignKey work in this case, though, where ContentType is in a different database?