-
-
Notifications
You must be signed in to change notification settings - Fork 7k
Special case for when OneToOneField is also primary key. #5192
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
Conversation
import ordering matters
Looks great! Nice work 😄 |
I think I may have found another related edge case here. I'm being faced with a 'view_name' argument is required AssertionError whilst trying to use DRF 3.9.1 (also with 3.9.0). The stack trace looks like...
The only thing I'm changing from having a working return, is that I'm overriding the
If I remove the The edge case may be a result of my working with a legacy Database that is read-only and whose schema was defined by third-parties. The only models to have problems with the modified serialiser above are the ones with a OneToOneField as their primary key, e.g.:
or
...which would seem to rule out it being an issue related to naming conventions for FKs. I'm now a little lost and lacking the time to dig deeper into DRF's workings here, so I'm hoping that something obvious will jump out to this audience as they've looked at this issue already. I should add that I'm chasing this solution as having to add all the fields specifically is something of an immense ask on a DB with 6000+ tables, some with near 100 columns - using Suggestions please?
|
Additionally, having tried to manually list all the fields on one of the smaller tables, I get the same error:
and that's with a model of...
and a serialiser of:
This makes me suspect the problem is a bit deeper on the OneToOneField as PK and not just related to adding in the PK to the default_fields. |
The discussion group is the best place to take this discussion and other usage questions. Thanks! |
Noted, thank you, and posted... |
Description
Closes: #5135
I've been working this issue occasionally since the last day of the PyCon sprints. I setup a test case to reproduce the problem from the issue and then iterated in a debugger to determine where I thought the best spot to make a code change was. I determined that
build_standard_field
feels like the right place for a couple reasons. One was that I first tried to do the change inget_field_names
except that expects all the results to be retuned Django fields and I am trying to override it to be the right serializer field. I followed the code further down and determined that it was falling back to the genericmodels.Field: ModelField
inserializer_field_mapping
.I found two convenient attributes on the field class which is
one_to_one
andprimary_key
so if both are True then we know we have to handle this special case. If you comment out the three code lines in the serialziers.py it will fail my newly added tests for this case.Please let me know if you think this change should be amended somehow, but my confidence level is high enough now to put out a PR for fixing this issue as I didn't think of anything else that needs to be considered.