Schema validation support?? #71

Activity

1. lelit commented on Apr 22, 2017

   

   lelit

   on Apr 22, 2017

   Contributor

   More actions

   No: can you expand a little on what would be needed?
2. sbellem commented on May 22, 2017

   

   sbellem

   on May 22, 2017

   Contributor

   More actions

   This is something we are interested in at @bigchaindb as we were able to speed up our validation by a factor of 3, using rapidjson with this rough first cut (by @libscott): https://github.com/bigchaindb/python-rapidjson-schema (the wrapping code is under https://github.com/bigchaindb/python-rapidjson-schema/blob/master/schema.cpp).

   We are now wondering what would it take to transform this rough work into an acceptable pull request for you as we would rather have python-rapidjson support the schema validation than use our own isolated approach.

   👍React with 👍1Reacted by Ken Robbins
3. lelit commented on May 22, 2017

   

   lelit

   on May 22, 2017

   Contributor

   More actions

   Thank you, I will try to have a look and better understand it in the following days.

   👍React with 👍1Reacted by Sylvain Bellemare
4. sbellem commented on May 23, 2017

   

   sbellem

   on May 23, 2017

   Contributor

   More actions

   Thank you, I will try to have a look and better understand it in the following days.

   Thanks a lot!

   /cc @libscott @r-marques
5. lelit commented on Jul 3, 2017

   

   lelit

   on Jul 3, 2017

   Contributor

   More actions

   I spent some time on this, and I have a couple of questions:

   1. in your implementation, I see that here you create a new SchemaDocument, that does not seem being freed (there's no tp_dealloc on the Python type): being a newbie in C++, is that correct?
   2. how would this integrate with the PyRJ extensions such as datetime handling for example? Should the validation happen at the lowest level (that is, on plain JSON stream), or should the new Schema object validate() method accept most of the arguments current rapidjson.loads() accepts?
6. ssadler commented on Jul 4, 2017

   

   ssadler

   on Jul 4, 2017

   More actions

   1. It's quite possible that the python type is missing a call to deallocate the SchemaDocument. In our use case it is not needed since the SchemaType is only loaded once and is not freed. I made an issue.
   2. Not sure. I suppose that ideally it would be flexible but I don't know how rapidjson extensions work. It seems like you might be constrained by the interface rapidjson::Document d; accept = d.Accept(validator);.
7. lelit

   added a commit that references this issue on Aug 17, 2017

   First cut at a Validator class

   ...

   2b06e64
8. lelit commented on Aug 17, 2017

   

   lelit

   on Aug 17, 2017

   Contributor

   More actions

   @libscott, could you give a look and tell me how it sounds?
9. lelit commented on Aug 24, 2017

   

   lelit

   on Aug 24, 2017

   Contributor

   More actions

   Implemented in version 0.2.
10. lelit

    closed this as completedon Aug 24, 2017