Earlier quoted context omitted.
Sorry on the slow reply. But yea, I can complain at length. - Model validations aren't run automatically. Need to call full_clean manually. - EXCEPT when you're in a form! Forms have their own clean, which IS run automatically because is_valid() is run. - This also happens to run the model's full_clean. - DRF has its own version of create which is separate and also does not run full_clean. - Validation errors in DRF'…
Thanks for your reply. I'm currently in a stage of falling out of love with Django and trying to get my thoughts together on why that is. I think Django seems confused on the issue of clean/validation. On the one hand, it could say the "model" is just a database table and any validation should live in the business logic of your application. This would be a standard way of architecting a system where the persistence l…
For us we separate validations in two. Business and Data validations, which are generally defined as:
- Business: The Invoice in Country X is needs to ensure Y and Z taxes are applied at Billing T+3 days otherwise throw an error.
- Data Validation: The company's currency must match the country it operates in.
Business validations and logic always go inside services where as data validations are on the model. Data validations apply to 100% of all inserts. Once there's an IF statement segmenting a group it becomes business validation.
I could see an argument as to why the above is bad because sometimes it's a qualitative decision. Once in a while the lines get blurry, a data validation becomes _slightly_ too complex and an arguement ensues as to whether it's data vs business logic.
Our team really adheres to services and not fat models, sorry DHH.
To me, it's all so controversial whatever you pick will work out just fine - just stick to it and don't get lazy about it.