From experience I have a very strong preference for putting enumerations into a separate enums.py file alongside the models.py — could you try this approach and see how it looks/works for you? It might not be suitable, but definitely worth having a look at...
I worry that we have too many nullable (or quasi-nullable with NONE enum value) here. These are pretty common sources of bugs. Can I suggest trying a "hanging table" approach and seeing how that feels? eg.
Note that crucially field_c and field_d are not nullable as you only create ExtraData models when you know you have both of those fields, so there is no possibility of having field_c but not field_d etc. etfc.
Nice @vessemer. What do you think of the separate enum file approach? The only thing I would ask now is that you rename it to enums.py as Python already ships with an enum module so this clashes... *g*
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.