Nebojša Đorđević wrote: > On 2006-02-22, at 11:18 CET, hugo wrote: > >> 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. > > I'm definitely +1 on this, when I'm looked trough my current code- > base I found lot's of examples of creating invalid objects and later > (before .save()) adding required data to make it valid and (as > someone else also pointed out) I have more than few cases of mutually > dependent fields which can't be changed in one property access.
I have one script that intentionally causes validation failures (it auto-populates a slug field, based on data it is marshalling from an outside source), that I want to make sure I have the ability to turn off validation to leave the script an automatic process (slug ambiguities are easy to correct in the admin). -- --Max Battcher-- http://www.worldmaker.net/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---