-
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Set pk_field=UUIDField for UUID foreign keys #8791
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -265,6 +265,8 @@ def get_relation_kwargs(field_name, relation_info): | |
kwargs.pop('queryset', None) | ||
if model_field.null: | ||
kwargs['allow_null'] = True | ||
if isinstance(model_field.target_field, models.UUIDField): | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I find it a bit awkward to introduce special handling for one field type while everything else is basically ignored. Sure, PKs are for the most part either Having more specific types seems reasonable, but then it should be done consistently and across the board imho. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agreed, I was only thinking of integer, string, and UUID keys at the time but I can definitely see the value in supporting more fields. Is there any reason we wouldn’t want to use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is just something that I noticed and thought it would be worth mentioning. Someone more knowledgeable on these parts should probably chime in on that question. @auvipy? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. my thought here is, we should initially consider prospective primary key types / fields mapping here initiallly There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I meant most commonly used primary key types checking / special could be done initially There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
We can use / try it here as well There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Looked into this a bit— since some of the field types also need kwargs, we'd probably want to use We could just make |
||
kwargs['pk_field'] = models.UUIDField() | ||
if kwargs.get('read_only', False): | ||
# If this field is read-only, then return early. | ||
# No further keyword arguments are valid. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The test suite lands here only for
field_class==HyperlinkedRelatedField
It seems this change is neither covered by the new tests nor is it required as the new tests do pass without this addition.