Difference between revisions of "Ceilometer/ComplexFilterExpressionsInAPIQueries/ValidationWithColander"
(→Colander for complex query filter syntax validation) |
|||
| Line 1: | Line 1: | ||
=Colander for complex query filter syntax validation= | =Colander for complex query filter syntax validation= | ||
| − | The goal was to find a way to validate the filter syntax with colander. Here is my brain dump recorded during the process, with all the explanations and wondering http://paste.openstack.org/show/ | + | The goal was to find a way to validate the filter syntax with colander. Here is my brain dump recorded during the process, with all the explanations and wondering http://paste.openstack.org/show/61473/ I suggest to read it before jumping to the conclusion. |
To sum it up colander is not flexible enough to parse and validate an expression tree with variable node types because: | To sum it up colander is not flexible enough to parse and validate an expression tree with variable node types because: | ||
Latest revision as of 20:51, 17 January 2014
Colander for complex query filter syntax validation
The goal was to find a way to validate the filter syntax with colander. Here is my brain dump recorded during the process, with all the explanations and wondering http://paste.openstack.org/show/61473/ I suggest to read it before jumping to the conclusion.
To sum it up colander is not flexible enough to parse and validate an expression tree with variable node types because:
- It cannot make validation rules about the key names in a dictionary. If every dynamic data is moved to the values then the type of a value will depend on the content of another value on the same level. This cannot be expressed with colander.
- If at a key the value can have more than one types, then it cannot be expressed with colander, because colander does not support OneOf for types just for validators
In the other hand, all the above things can be expressed and validated with jsonschema without a need to write loops and conditions, as proposed in the https://review.openstack.org/#/c/62157/
I can imagine that colander is a good candidate to replace wsme in the API layer, as it is more flexible than wsme but it is far less flexible than jsonschema. So I think if we replace wsme with colander, then we still need jsonschema to validate the filter syntax of the complex query.
