On Sep 28, 2011, at 10:08 AM, Kirk Strauser wrote: > I get what you're saying, truly, and agree with the underlying argument: SQLA > is an ORM, not a data validator, template parser, or cheese grater. But I > would contend that the kind of validations I'm proposing would operate on the > level SQLA occupies. What I had in mind wouldn't answer the question "does > this column contain the correctly spelled name of a Pantone color?", but "is > the data in this column capable of being stored in the underlying database?" > > For instance, if Model.foo is Column(Integer), and the client app sets it to > "creqcrq", then most databases (ignoring SQLite for the moment) will balk at > insertion time. Similarly, PostgreSQL won't let you store "value" in > Column(String(1)). If my model has already defined that column as a > String(1), it'd be convenient if I could ask SQLA if the object I've just > created can even be stored.
SQLA is very loathe to duplicate what the DBAPI and/or database already does. These use cases are all already covered, the issue here is wanting those validations to be duplicated under the specific use case that invalid values should be skipped, instead of halting the operation. This already cuts down the usefulness of such a feature to a small percentage of projects. The scope of column-based validations we can do is limited. "nullable" is simple, sure. 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. Other validations that can be derived from schema include CheckConstraint. It contains a SQL expression - if it's a string, we can't test it without going to the database. If it's derived from a SQL expression construct, we can use the techniques in orm.evaluator to run an extremely limited subset of that expression, it would be awkward, it would fail all the time due to all kinds of database-specfic SQL functions we don't have a translation for. To get Python-side validation here, the user probably has to supply an in-python validation function separately from the constraint itself (and we have hooks for that). Another one, UniqueConstraint. How do we check that in Python without hitting the DB ? not really possible. Same for ForeignKeyConstraint. I didn't mention this last time but we do have almost everything you need to do "validations" except for the validation functionality itself - the @validates decorator and its more generalized version, the attribute set event, receives the attribute, the value, all you need to do is take a look at the Column passed in, associated with the incoming attribute. From there you can look at "nullable", and maybe check within five or six possible types that are built-in. It still seems like a trivial amount of code for anyone to do for a specific subset of validations - to do it for a very wide range of validations, as a built-in feature demands, its an enormous job which would require a ton of testing and would almost never be used as it would be an unnecessary performance hit for a job the database already does much better. SQLAlchemy itself really cannot implement such a feature in any reasonable way, it would have a huge amount of holes in it. It is definitely best as a third party project, the hooks are there. -- 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.
