On Sep 28, 2011, at 9:45 AM, Michael Bayer wrote: > Also, there are type-based validations, fine, string, numeric, integer, > dates, including length of strings. If someone throws on postgresql.INET, > not really, unless the contract of TypeEngine objects is extended such that > they *all* get in-python validation functions. Which is really, really > redundant, as DBAPIs do that most of the time. Very heavyhanded for very > little use - we definitely don't want these validations turned on all the > time as they'd kill performance unnecessarily. String length in particular, > we have to deal with unicode conversions before checking length, some > databases store unicode as "number of chars" others as "number of encoded > bytes", it's complicated, and entirely redundant vs. what the database > already does.
OK, you've convinced me. I hadn't taken those cases into consideration; they don't come up much in the stuff I'm working with. For the record, though (in case anyone ever Googles this and wonders what I was thinking), I never thought of this as a mandatory behavior but as something that would be there if you wanted to use it, like: >>> from sqlalchemy import getvalidationerrors >>> newobj = MyClass(column1='foo', column2='bar') >>> for error in getvalidationerrors(newobj): [...] Anyway, thanks for the pointers to a workable ad-hoc approach. - Kirk -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
