-
Notifications
You must be signed in to change notification settings - Fork 53
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
Improve default= handling on MoneyField #60
base: master
Are you sure you want to change the base?
Conversation
Codecov Report
@@ Coverage Diff @@
## master #60 +/- ##
=======================================
Coverage 96.15% 96.15%
=======================================
Files 4 4
Lines 104 104
Branches 10 10
=======================================
Hits 100 100
Misses 2 2
Partials 2 2 Continue to review full report at Codecov.
|
Does that mean that we accept integers/strings as default values? Won't that cause even more problems? |
I don't think it would cause errors. Still, our API's shouldn't cause raising eyebrows, and seeing how money becomes string in migration may be causing such eyebrow raise. So I've replaced this with just returning |
What would call |
@patrys the path here is roughly |
This PR improves our handling for scenario when
MoneyField.default
is of typeMoney
:MoneyField.__init__
validates thatMoney.currency
is same as one passed in thecurrency
argument, and raisesValueError
otherwise, so its impossible to create model with field as such:MoneyField.deconstruct
tests if default value is instance ofMoney
, and if that is the case, deconstructskwargs['default']
tostr(Money.amount)
, so migrations generated by Django don't importprices
and don't construct explicitMoney
, which should make them more future-proof.If somebody out there already has model like in our
InvalidModel
change, this will be breaking change for his/her project.