Hi all,
This comes from trying to fix #24343[1] -- a problem where a UUIDField is used
as a PK (legitimate and common practice), and we wish to test a FK to that
model. The problem is that, on database backends which do not support native
UUIDFields (that is, all but postgres), the underlying field for an FK is a
CharField, not a UUIDField. This is not a problem in most normal use, but
sometimes people do access the underlying field, and they're in for a surprise
there.
I am almost certain that a similar problem exists with any non-trivial field --
e.g. if someone had reason to use a CommaSeparatedIntField as a PK, they would
probably run into the same issue.
Now, there are two essential ways to fix the test failure in the ticket: One,
as suggested by Tim in a comment on the ticket, is to just deal with the
difference in the test. The other is to solve the deeper issue, which could be
seen as a little disruptive at this point in the release cycle (and is, in
general, more disruptive).
Note that, as Tim notes on the ticket, the test failure is Oracle only, but
the real issue is everyone-but-postgres.
Opinions?
Thanks,
Shai.
[1] https://code.djangoproject.com/ticket/24343
