Skip to content
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

Refactor JobValidator to remove inheritance from DRF Serializer class to clarify purpose #9513

Open
rtibbles opened this issue Jun 13, 2022 · 0 comments
Assignees
Labels
DEV: backend Python, databases, networking, filesystem... TAG: developer docs Technical docs and code comments TAG: tech update / debt Change not visible to user

Comments

@rtibbles
Copy link
Member

We are currently using the validation and deserialization mechanisms from Django REST framework to process data coming from both API endpoints and internal programmatic sources.

This can cause confusion for developers about the intended role for the JobValidator - is it primarily a deserializer for Job data coming from an API endpoint, or is it primarily intended to perform validation? See e.g. #9493 (comment)

To clean this up, the base JobValidator should minimally inherit from DRF classes to the extent required to perform the validation without vendoring the entire Serializer if possible.

At the very least, we the class would need to inherit from the Serializer metaclass in order to properly handle the way DRF sets fields to be available for validation.

@rtibbles rtibbles self-assigned this Jun 13, 2022
@rtibbles rtibbles added TAG: tech update / debt Change not visible to user TAG: developer docs Technical docs and code comments DEV: backend Python, databases, networking, filesystem... labels Jun 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
DEV: backend Python, databases, networking, filesystem... TAG: developer docs Technical docs and code comments TAG: tech update / debt Change not visible to user
Projects
None yet
Development

No branches or pull requests

1 participant