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).
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.
To sum up, I think this would be very hard to implement and not provide a
consistent user experience in the end.
--
Aymeric.
--
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/ABB44ECA-7B2E-4539-AFC1-EECE934B6A96%40polytechnique.org.
For more options, visit https://groups.google.com/groups/opt_out.
