-
-
Notifications
You must be signed in to change notification settings - Fork 87
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
[116] Support Callable default
and Always Use default
If Present
#117
[116] Support Callable default
and Always Use default
If Present
#117
Conversation
- Also, always generate default value if `field.default` is supplied - Previously, this would not happen, since the `generator` determination was being done earlier in the same `if, elif` block - Add unit tests for generating default value of callables of varying kinds
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.
LGTM! 👍🏽
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.
Thanks for your PR @timjklein36
assert person.enjoy_jards_macale is enjoy_jards_macale_field.default | ||
assert person.like_metal_music is like_metal_music_field.default |
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.
Thanks for this catch! I didn't notice that the assert
was wrong before
#117 introduced an issue for cases where `id` values is provided as a default for foreign keys. This PR attempts to fix that issue by checking if generated value for FK field is an instance of this model - if not it uses `_id` as a field name (https://docs.djangoproject.com/en/3.1/ref/models/fields/#database-representation).
* Allow id to be used as FK default (Fix #136) #117 introduced an issue for cases where `id` values is provided as a default for foreign keys. This PR attempts to fix that issue by checking if generated value for FK field is an instance of this model - if not it uses `_id` as a field name (https://docs.djangoproject.com/en/3.1/ref/models/fields/#database-representation). * Another fix idea: use default unless given custom argument * Remove old way, do some cleanup * Update CHANGELOG.md
What
This change fixes #116, the following bug:
For instance:
This also addresses the fact that the
default
value for a field was not always being returned fromBaker.generate_value
since it was lower in theif, elif, else
block which also checked for the generator function to use for that field's value.Note: This PR takes the stance that: if
default
is present, that value should be used unless an explicitkwarg
for that field is supplied tomake
.Why
This will allow fields of classes that are unknown to
model_bakery
, yet have a desireddefault
value, to be used without error.