>* This plan is nice conceptually because it doesn't leave any chance >of bad data in any model instance. Currently, Django is "dumb" about >data in model instances -- it allows any arbitrary data there, and >catching bad data is completely the responsibility of the developer. >This can lead to some IntegrityErrors at the database level (search >the django-users mailing list archives for examples) when the >developer forgets to validate.
Hmm. I see problems with validators that validate a lot of fields against each others. For example think about this (stupid and simplified, just to show what I am talking about) sample: a validator that requires two fields to be identical. You can create such an object by instantiation - but you can't change it later on, as you have to change one attribute a time, but since two attributes must be identical, you won't be able to change those two fields ... A more realistic sample might be a situation where one field must be within a range given by two other fields - you will have to make changes to those attributes in a way that allways keeps the validators happy. I would propose to instead do validation in those situations where the data is moved to the external storage - on .save() (or in the unit-of-works .save() if we have them). That way you can happily create invalid objects, but you will be forced to make them valid to save them. An additional .validate() method could be introduced that will trigger validation without saving to allow programmers to do early validation if they need to. All this with bonus points for keeping an internal flag on the object that tells wether this object is "validated" or "dirty" with __setattr__ (or actually property access) automatically marking objects as "dirty", so that the implicit .validate() within .save() isn't needed if early validation was used. bye, Georg --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
