On Sep 27, 2011, at 1:56 PM, Michael Bayer wrote: > OK so the aspect you're looking for here is to define those validations just > once, this is easy enough through a recipe like this: > > def notnull(key): [...] > > def get_validators(someobject): [...] > > def validate(someobject): [...]
Yep, that's pretty much what I had in mind. > The above recipe lacks a lot of features one might want, such as customizable > ways of defining the validation failure, behavior on the receipt of a failed > validation, etc. A full blown "validation" library might use the idea > above but expand upon it in a much bigger way. I've had other ad-hoc > validation use cases that wouldn't work with the above structure, instead > needing a slightly different structure, so having a small thing just as code > for now is more flexible than a built in "feature" that only handles a small > subset of use cases. 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. > You might want to check around if similar things don't exist already, I did > find http://pypi.python.org/pypi/SAValidation/ and > http://pypi.python.org/pypi/sqlalchemy_elixir_validations/ for example, there > might be features there that are of use. But by all means, produce a better > validation library for SQLAlchemy, the more the merrier and I'd love to see > more. The ones I've found are pretty high-level form validation stuff. Which is well and good! I'm glad we have those types of things. I'm looking for something more akin to checking for type safety, though. If I can get something usably working, I'll toss it up on Github for everyone's amusement. :-) - 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.
