UUID foreign key accessor returns inconsistent type

[Tim Graham]

Current test failure on Oracle (and it's an issue on other backends but tests are skipped on other backends besides Oracle and PostgreSQL due to @skipUnlessDBFeature("can_defer_constraint_checks"):

Traceback (most recent call last):
  File "/mnt/jenkinsdata/workspace/django-oracle/database/oracle11/python/python2.7/django/utils/functional.py", line 15, in _curried
    return _curried_func(*(args + moreargs), **dict(kwargs, **morekwargs))
  File "/mnt/jenkinsdata/workspace/django-oracle/database/oracle11/python/python2.7/tests/serializers_regress/tests.py", line 479, in serializerTest
    func[1](self, pk, klass, datum)
  File "/mnt/jenkinsdata/workspace/django-oracle/database/oracle11/python/python2.7/tests/serializers_regress/tests.py", line 154, in fk_compare
    testcase.assertEqual(data, instance.data_id)
AssertionError: UUID('3f57e641-c3c7-4990-be67-f3207e4f5bd2') != u'3f57e641c3c74990be67f3207e4f5bd2'

Give this model:

class FKToUUID(models.Model):
    data = models.ForeignKey(UUIDData)

obj.data_id returns a string on all backends except PostgreSQL which returns a UUID. Might be related to the has_native_uuid_field database features flag.

[Tim Graham]

If the current behavior is correct, here's a patch to simply make the test pass:

diff --git a/tests/serializers_regress/tests.py b/tests/serializers_regress/tests.py
index e98a721..de2c0fc 100644
--- a/tests/serializers_regress/tests.py
+++ b/tests/serializers_regress/tests.py
@@ -151,6 +151,8 @@ def generic_compare(testcase, pk, klass, data):
 
 def fk_compare(testcase, pk, klass, data):
     instance = klass.objects.get(id=pk)
+    if isinstance(data, uuid.UUID) and not connection.features.has_native_uuid_field:
+        data = str(data).replace('-', '')
     testcase.assertEqual(data, instance.data_id

[Shai Berger]

Is there a reason why we don't test the fk by accessing it?

That is, shouldn't we be doing something like

testcase.assertEqual(instance.data.pk, data)

?

[Shai Berger]

For the people following this ticket: My suggestion above does not work, and is in the wrong direction. What appears to be the right direction is ​Marc's PR, following the little ​mailing list discussion.

[Marc Tamlyn <marc.tamlyn@…>]

In 4755f8fc25331c739a6f932cc8aba0cc9e62e352:

Fixed #24343 -- Ensure db converters are used for foreign keys.

Joint effort between myself, Josh, Anssi and Shai.

[Marc Tamlyn <marc.tamlyn@…>]

In c54d73ae01cd787315ba030da17e266c49f386b3:

[1.8.x] Fixed #24343 -- Ensure db converters are used for foreign keys.

Joint effort between myself, Josh, Anssi and Shai.

Conflicts:

django/db/models/query.py
tests/model_fields/models.py

Backport of 4755f8fc25331c739a6f932cc8aba0cc9e62e352 from master.

[Tim Graham <timograham@…>]

In 5e3463f6:

Fixed #27595 -- Made ForeignKey.get_col() follow target chains.

Previously, foreign relationships were followed only one level deep which
prevents foreign keys to foreign keys from being resolved appropriately.
This was causing issues such as improper database value conversion for
UUIDField on SQLite because the resolved expression's output field's
internal type wasn't correct. Added tests to make sure unlikely foreign
reference cycles don't cause recursion errors.

Refs #24343.

Thanks oyooyo for the report and Wayne Merry for the investigation.