Support for additional constraints in various data types

[dexter2206]

Some OpenAPI types can have additional constraints (min/max, boundaries on number of items in array etc.) that should be supported. Full list can be found in specification.

[dexter2206]

After considering current architecture I think we should also implement format keyword (or at least plan accordingly so that keyword can be later implemented). I would also like to keep the possibility of controlling some building aspects (as for instance data type that is created upon deserialization). Therefore here is what I suggest:

• implement various validation aspects (min/max, minItems etc.) as validators that can be passed to marshmallow fields. Alternatively we could go for a single class for constructing all primitive types, but I feel this would stand against single responsibility principle.
• reimplement primitive builders so that they are more than shallow classes holding their field type. Instead, they could contain logic for constructing appropariate validators. Instances of those classes can also store their field type (by default set to the ones stored in class variables at this moment).
• add the possibility to override those default field classes in build_schema
• resign from the possibility of user passing custom builders - only the field classes would be controllable,
• the fields would be our custom fields (inheriting from marshmallow fields). Those fields would accept format parameter. By default it would do nothing, but for user defined fields it could allow to construct objects of specific datatypes (think of constructing numpy.float32 objects for numeric schemas with format set to single).

I could implement all of the above. @magdanowak what do you think?

[magdanowak]

I'm for implementing the validators, and primitive builders seem to be the right place to do it. Right now something similar is done in ObjectBuilder with requirement parameter, so you can take a look. Are all possible constrainsts implemented by marshmallow, or do any need to be implemented by us? Might be good to separate those into another issue.

I would do the rest in a seperate issue. As I mentioned before, I don't feel like letting the user pass custom builders or create user defined fields is a priority at this stage. From your proposal I understand that the aspects of a field the user would be able to control is the field type name and add a format, is this correct?

[dexter2206]

Some constraints are implemented in marshmallow, but most of them have to be implemented separately. I will create an issue with the details.

User-defined customizations are not a priority but I think we should plan so we won't have to rewrite everything from scratch when we plan to add it. For now, I think that only leaving the option for controlling field class would be ok. So the user would only control class (i.e. pass something reasonable instead of marshmallow.fields.Integer), with reasonable defaults defined. Implementing format is also crucial as 1) this is one of the constraints (although not a strict one), and 2) this is where user-defined fields can shine As I mentioned earlier it would be cool to pass fields that would deserialize e.g. into numpy objects, we could create plugin implementing such fields - it would be great for implementing APIs dealing with scientific computing.