Sounds good. I guess that may be an addition here: https://docs.djangoproject.com/en/dev/ref/models/instances/#validating-objects
On Tuesday, October 22, 2013 8:40:46 AM UTC-4, Cal Leeming [Simplicity Media Ltd] wrote: > > 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]<javascript:> > > 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] <javascript:>> 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] <javascript:>> 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]<javascript:> >>>> > 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] <javascript:>. >>>>> To post to this group, send email to >>>>> [email protected]<javascript:> >>>>> . >>>>> 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] <javascript:>. >>> To post to this group, send email to >>> [email protected]<javascript:> >>> . >>> 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] <javascript:>. >> To post to this group, send email to >> [email protected]<javascript:> >> . >> 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/fd03bf57-154a-41a0-9f20-aa569d62114d%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
