On Sun, Mar 2, 2014 at 1:07 AM, Aymeric Augustin < [email protected]> wrote:
> On 1 mars 2014, at 09:14, Martin Matusiak <[email protected]> wrote: > > > Now in the case of sqlite, which is very permissive, it will happily > > accept values like 1 and {} and store them as "1" and "{}" (wtf) > > respectively. So if I'm running my tests against sqlite I won't even > > know that this will bite me in production. > > You should never, ever, for any reason, use a different database in > development, test and production. It's a bad idea. It doesn't work. > > > The thing is that it would be pretty easy to provide a strongly typed > > model layer using descriptors. So that every time I assign to > > bill.name it will raise ValidationError if the value isn't a string, > > if the string is longer than max_length etc. Is there a rationale for > > why we don't do this? > > An important reason is performance. If creating and saving an instance with > 10 fields took 0.01 seconds, that would be poor. For the same reason, > Model.save() doesn't call Model.full_clean() (unless you override it). > Correcting the record here - the reason Model.save() doesn't call Model.full_clean() is historical, not performance. Model validation wasn't added until v1.2, and we couldn't work out a way to introduce enforcement of model validation without potentially breaking existing code. There may be a performance reason as well, but that was a secondary concern at the time. > A structural reason is that you can't tell "assigning an attribute to an > instance in order to save it to the database later" apart from "assigning > an > attribute to an instance being loaded from the database". So your proposal > doesn't play nice with lazy loading of related instances, for example. > > Another reason is the impossibility of running validations involving > multiple > fields. If a validator depends on the value of two fields, one has to be > set > before the other, and you can't validate at that point. > For me, this is the bigger reason why validation at time of assignment isn't viable. In order to do multi-field validation at time of assignment, we'd need to introduce some sort of transactional behaviour. Just thinking about this makes my brain hurt. Alternatively, we'd need to introduce validation for single fields, but not enforce cross-field validation until object save. This strikes me as fundamentally confusing behaviour. > To sum up, I think this would be very hard to implement and not provide a > consistent user experience in the end. > I concur. Yours, Russ Magee %-) -- 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/CAJxq8485-hPcdKmOXFJxh0z2FjEkoyBsyVVMsBXGms6wRpjBgQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
