Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Length validation fails on UUID fields #54
It appears that schemas for models with custom column types, which have a
The column type is basically the example from the SQLAlchemy docs, with the addition of a
I could just use the
I was curious about this issue as well (though it's maybe more broad than this particular ticket). It seems like there could be other instances of this same phenomenon around any sqlalchemy TypeDecorator's/custom types, where the deserialized python type doesn't fit validation extracted from the column. For instance, a datetime stored as a fixed length string would have the same issue (not that this is a good idea compared to using DATETIME etc, just by means of example). Any thoughts on how to address the more general issue where validators that make sense for the sqlalchemy implementation type (e.g. CHAR) don't make sense for the python type (e.g. UUID)? Special casing UUID solves the immediate issue, but it seems like it might pop up in other circumstances as well.
Very good point @andrewmains12 . One approach would be to remove automatic addition of validators and leave it up to the user to opt in to validators.
I prefer to keep the automatic validators because they meet the "90% use case". Special-casing UUID in this case is justified because marshmallow-sqlalchemy has built-in support for the UUID sqlalchemy type.
So I think the best approach for handling other types is to let the user opt out of the automatically-added validators, which they can do using
full_name = field_for(models.Student, 'full_name', validate=)