Fixed #24698 and #24712: Implement get_db_prep_value for ForeignKey #4644
Conversation
abhaga
force-pushed
the
ticket_24698_24712_1_8
branch
2 times, most recently
from
df02a65
to
da38886
Compare
|
I think it would be better to add tests for the failing queries rather than the lower level implementation details -- |
|
I thought of that but then decide to go with testing the common cause linking the two tickets this solves. Should I include tests based on the queries from both the tickets? Despite looking different on the face, they go through the same code path in the end - generating a where clause on a related field point to a UUIDField. The example in 24712 is quite minimal. So perhaps including only that one should suffice? |
|
No strong opinion from me. I guess we'll need to add new models either way. |
abhaga
force-pushed
the
ticket_24698_24712_1_8
branch
3 times, most recently
from
4fd339c
to
77f3633
Compare
…ignKey Due to missing get_db_prep_value on ForeignKey, UUIDField was generating the wrong lookup values in db queries. Tests for ForiegnKeys to models with UUIDField primary key
abhaga
force-pushed
the
ticket_24698_24712_1_8
branch
from
77f3633
to
a9e2d9c
Compare
|
buildbot, test this please. |
|
merged in 290c9d6 after some light edits, thanks! |
|
Thanks! |
ForeignKey was not deferring to related field for get_db_prep_lookup. As a result, the db_prep_save value would differ from db_prep_lookup value for foreign keys pointing to fields that implement a custom get_db_prep_value.
Add a tests checking specifically for a ForeignKey to a UUIDField.