It seems there is a split reaction on whether or not models should assume data is clean, and comes down to design decision.
I think that a docs patch explaining this entire concept to new users would be sufficient for now (and I'm more than happy to spend time writing it). Would any of the core devs object to such a patch? Cal On Fri, Oct 18, 2013 at 8:19 PM, Marc Tamlyn <[email protected]> wrote: > I think Anssi summed up my feelings on this very well, in particular with > the issues with update(). Similarly create() would also bypass as it does > not call save() AFAIK. > > Given these commonly used approaches do not work, and that the name of the > method - save() - implies only saving to the database - I'm -1 on save() > calling clean(). > > That said, there is an interesting option to explore in ModelForms as to > how to push more if the validation to the database where that's > appropriate. This would increase the performance of write-heavy sites, and > also enforce better data integrity. At the moment all cleaning is done > before the instance is saved, and the assumption is that the instance will > pass db validation. As far as I know, we don't currently have any code > which detects problems there (dB integrity errors) and ties them back to > the fields or instances which have caused the issue. This is obviously > backend-specific code, and is far from straightforward. I think some of the > pending ValidationError changes could make it possible. > > Anssi and Andrew - do you think the dB can actually tell is enough > information to get this right? I guess if not an option would be to fall > back to the current query-creating code to work out why the save failed. > > Most of this is throwing thoughts around, apologies if they're illogical… > > Marc > On 18 Oct 2013 15:18, "Cal Leeming [Simplicity Media Ltd]" < > [email protected]> wrote: > >> Sorry please ignore my last email, my email client went a bit weird and >> sent the draft whilst I was still editing/thinking. Here is the proper >> version; >> >> This is yet another reason why I don't think it would be reasonable to >> expect field validation within the model. >> >> If the validations were done using DB constraints (as per Anssi's reply) >> then this would be a reasonable expectation, however as mentioned before >> changes in the field data can come from multiple places and it is not safe >> to assume that any data in the model is ever going to be valid. >> >> I think if the developer understands why this is important, they would be >> adding a lot of code to handle these different scenarios anyway, so I don't >> think removing the need to call full_clean() manually would be of much >> benefit. >> >> However that being said, I would be in favour of adding a call which >> allows you to validate changed and/or all fields, making it easier to >> handle these different validation scenarios. (i.e. being able to easily >> detect if it is old data that has caused validation error, or new data). >> >> Cal >> >> >> >> >> On Fri, Oct 18, 2013 at 3:09 PM, Cal Leeming [Simplicity Media Ltd] < >> [email protected]> wrote: >> >>> This is yet another reason why I don't think it would be reasonable to >>> expect field validation within the model. >>> >>> I also think that introducing such a check would not only lure the user >>> into a false sense of security >>> >>> If the validations were done using DB constraints (as per Anssi's reply) >>> then this would be a reasonable expectation, however as mentioned before >>> changes in the field data can come from multiple places and it is not safe >>> to assume that any data in the model is ever going to be valid. >>> >>> Given the performance concerns and the minimal amount of benefit that >>> validating on save() would give, >>> >>> >>> On Fri, Oct 18, 2013 at 2:42 PM, Florian Apolloner < >>> [email protected]> wrote: >>> >>>> >>>> >>>> On Friday, October 18, 2013 4:28:21 AM UTC+2, Karen Tracey wrote: >>>>> >>>>> Wasn't there also concern for double validation performed during form >>>>> clean and then model instance save? >>>>> >>>> >>>> Yes, technically we would probably have to track the validation state >>>> per field and also track changes to it etc… :( >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Django developers" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected] >>>> . >>>> Visit this group at http://groups.google.com/group/django-developers. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/django-developers/31648978-7105-422f-ad62-68943e324a04%40googlegroups.com >>>> . >>>> >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CAHKQagFULsc%2BHRKxnR2i_4KZJjLNuPD8aHnbwnf1GjhzduopVg%40mail.gmail.com >> . >> >> For more options, visit https://groups.google.com/groups/opt_out. >> > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAMwjO1GYQHbAs2PAZHuYke%3DbJY7nNkXb%2BEbDb_9Ek3t2g%3D-ncA%40mail.gmail.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAHKQagE2k%3DxvRqhPNLMzfPGi5qufOqdj3wXsY7tqzSYuHJq4PA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
