-
Notifications
You must be signed in to change notification settings - Fork 301
Relation types only take into account model names which are not always correct. #166
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
Comments
It appears that I think an appropriate solution here would be to add an explicit I'll begin work on a PR with a failing test case and fix unless there are any concerns. |
While your proposed solution works for your use case, another discussion in another issue/pr (sorry I'm on my mobile) described the possibility of using a custom Meta class on the models to define custom types. |
Aha, I see #152 . I'm on board with that, and I think it's a more elegant way to handle it because it gets the data where it should be, on the model. It looks like the places that previously relied on _meta.model.name have been changed to point at that, as well. I'll close this issue in favor of that solution. |
I considered this a bit more this morning, and it came to me that there is another case that #152 does not cover that this type of solution may be appropriate for. There may be instances where for various reasons multiple serializers/API endpoints refer back to the same model. An override of this type would be useful in those situations as well. Thoughts? |
Proxy models? |
That is an elegant and simple solution that only someone who has been buried so long in his code that he forgot to come up for air can miss. 😂 Consider this closed. |
Example:
When invoked, the desired output for Task is:
However, the actual output is:
The text was updated successfully, but these errors were encountered: