2012/12/11 Alex Baranosky <alexander.barano...@gmail.com> > Christophe, one thing I've wondered about the design of clj-schema is > whether the schema is even the right place for determining looseness or > strictness. In some sense that is a property of the validation process. > It sometimes makes sense to use the same schema, but in some cases > validate it loosely or in other cases validate it strictly.
Isn't that the case already? I see that you put ::strict-schema metadata via the loose-schema / strict-schema functions ? i agree that schema could be defined without looseness / strictness information, and that it could be a property of the "validation run". In order for that to play well with composition of schemas, you may have to : - make schemas loose by default - allow to define strict schemas - allow to force validation in strict mode (would be loose by default, except of course for those schemas hard-defined as stricts) Some implementation questions : - couldn't strict-schema function be defined in terms of loose-schema function ( just assoc'ing the additional key to the result of calling loose-schema ?) - would it be possible to totally "free the data" ? :-), e.g. make it public that creating a strict schema requires a :clj-schema.schema true metadata on the vector of paths? Cheers, -- Laurent > > Laurent, what keeps you from just using `def-loose-schema`? > > > On Mon, Dec 10, 2012 at 1:02 AM, Christophe Grand > <christo...@cgrand.net>wrote: > >> Oh and clj-schema is really something I would use and promote. >> >> >> >> On Mon, Dec 10, 2012 at 10:01 AM, Christophe Grand <christo...@cgrand.net >> > wrote: >> >>> Hi Alex, >>> >>> To echo Laurent's concern: if you use schema to validate inputs you get >>> from another (sub)system then, in my opinion, a loose schema is a better >>> fit. >>> It's the must-understand/must-ignore schism once again. >>> Must-ignore (loose schemas) requires care when revising a schema (since >>> any piece of data valid under both schemas should not have its semantics >>> altered) but allows for forward-compatibility and, as such, reduces >>> coupling. >>> >>> Regarding your use-case (validation before storing): I see two >>> "complected" concerns: ensuring that you don't store bad data and ensuring >>> that you don't store too much. So, couldn't a loose schema be sued to first >>> validate the piece of data and then (or at the same time) prune extra keys? >>> >>> My two cents, >>> >>> Christophe >>> >>> >>> On Sun, Dec 9, 2012 at 9:45 PM, Alex Baranosky < >>> alexander.barano...@gmail.com> wrote: >>> >>>> Hi Laurent, >>>> >>>> It was originally written as loose-only, because that is an easier >>>> problem to solve, but since these schemas are being used at work to make >>>> sure no bad data gets stored in HBase we decided collectively that >>>> strictness was more of what we wanted. >>>> >>>> I'm open to exploring ways to make the default behavior of defschema be >>>> loose, perhaps via a binding. I could then create a third macro >>>> `def-strict-schema`... Let me know if you have any thoughts on approaches >>>> for this kind of modification. >>>> >>>> In general I'm open to ideas that help the library be more useful to >>>> people for their projects, so please feel free to shoot ideas by me. >>>> >>>> Alex >>>> >>>> >>>> On Sun, Dec 9, 2012 at 10:30 AM, Ambrose Bonnaire-Sergeant < >>>> abonnaireserge...@gmail.com> wrote: >>>> >>>>> I think Typed Clojure and clj-schema could work very nicely together. >>>>> I'll look at it again in a few months. >>>>> >>>>> Thanks, >>>>> Ambrose >>>>> >>>>> >>>>> On Wed, Nov 28, 2012 at 11:18 AM, Alex Baranosky < >>>>> alexander.barano...@gmail.com> wrote: >>>>> >>>>>> Hi Stathis, >>>>>> >>>>>> Thanks for your interestin clj-schema. If you use it and have any >>>>>> feedback please let me know. >>>>>> >>>>>> clj-schema is released under the MIT license: http://mit-license.org/ >>>>>> >>>>>> I think TypedClojure is really cool. I'm excited about both >>>>>> approaches because in general I'm very interested in approaches to coding >>>>>> that help us ensure that our code works correctly. That said there are >>>>>> some >>>>>> interesting differences in the approaches: >>>>>> >>>>>> - schemas can be used for other things other than validation or >>>>>> type checking. >>>>>> >>>>>> >>>>>> - schemas are more decoupled from the code. Say you are reading >>>>>> a map out of a file, or get a map returned from another library. With >>>>>> schemas you could easily validate the map. How would that be handled >>>>>> in a >>>>>> TypeClojure approach? Also, schema validation only checks at a >>>>>> snapshot in >>>>>> time; it makes no effort to ensure that that map is always correct. >>>>>> >>>>>> >>>>>> - schema validation happens at run-time; TypedClojure is a static >>>>>> analysis tool. ( Of course, if there was some kind of adapter for >>>>>> TypedClojure it could take schemas as params to the type >>>>>> declarations.) >>>>>> >>>>>> >>>>>> Alex >>>>>> >>>>>> >>>>>> On Tue, Nov 27, 2012 at 2:23 AM, Stathis Sideris >>>>>> <side...@gmail.com>wrote: >>>>>> >>>>>>> Hello Alex, >>>>>>> >>>>>>> This looks very useful, thanks. What's the license under which you >>>>>>> are releasing this code? Also, I'm wondering whether something like that >>>>>>> could be the next step for Typed Clojure. From Ambrose's thesis, I got >>>>>>> the >>>>>>> impression that he would like Typed Clojure to eventually cater for >>>>>>> checking the contents of maps. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Stathis >>>>>>> >>>>>>> >>>>>>> On Sunday, 25 November 2012 23:22:04 UTC, Alex Baranosky wrote: >>>>>>>> >>>>>>>> Clj-schema is a library for defining and validating schemas for >>>>>>>> maps, as well as for using those schemas to create valid test data. >>>>>>>> We've >>>>>>>> been using this in production for at least a few months now, at Runa. >>>>>>>> >>>>>>>> https://github.com/runa-dev/**clj-schema<https://github.com/runa-dev/clj-schema> >>>>>>>> >>>>>>>> The main benefits I've found from using this library are: >>>>>>>> * validating the inputs to the application: validating Ring request >>>>>>>> params and config files >>>>>>>> * validating before storing maps into the DB >>>>>>>> * using the clj-schema.fixtures library to create valid test data >>>>>>>> that stays valid. So as the standard form of a map changes over time >>>>>>>> the >>>>>>>> tests will stay in sync with those changes automatically. >>>>>>>> * there are some code-readability benefits as well - any developer >>>>>>>> can pretty quickly see what certain kinds of maps tend to look like. >>>>>>>> >>>>>>>> There's more info in the README: >>>>>>>> https://github.com/runa-dev/**clj-schema/blob/master/README.**md<https://github.com/runa-dev/clj-schema/blob/master/README.md> >>>>>>>> >>>>>>>> Future possibilities: >>>>>>>> * auto-generating test data from clj-schema fixtures >>>>>>>> * being able to create schemas for sets and sequences (currently a >>>>>>>> schema is always for a map) >>>>>>>> >>>>>>>> Contributors welcome. >>>>>>>> >>>>>>>> Alex >>>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Clojure" group. >>>>>>> To post to this group, send email to clojure@googlegroups.com >>>>>>> Note that posts from new members are moderated - please be patient >>>>>>> with your first post. >>>>>>> To unsubscribe from this group, send email to >>>>>>> clojure+unsubscr...@googlegroups.com >>>>>>> For more options, visit this group at >>>>>>> http://groups.google.com/group/clojure?hl=en >>>>>> >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Clojure" group. >>>>>> To post to this group, send email to clojure@googlegroups.com >>>>>> Note that posts from new members are moderated - please be patient >>>>>> with your first post. >>>>>> To unsubscribe from this group, send email to >>>>>> clojure+unsubscr...@googlegroups.com >>>>>> For more options, visit this group at >>>>>> http://groups.google.com/group/clojure?hl=en >>>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Clojure" group. >>>>> To post to this group, send email to clojure@googlegroups.com >>>>> Note that posts from new members are moderated - please be patient >>>>> with your first post. >>>>> To unsubscribe from this group, send email to >>>>> clojure+unsubscr...@googlegroups.com >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/clojure?hl=en >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Clojure" group. >>>> To post to this group, send email to clojure@googlegroups.com >>>> Note that posts from new members are moderated - please be patient with >>>> your first post. >>>> To unsubscribe from this group, send email to >>>> clojure+unsubscr...@googlegroups.com >>>> For more options, visit this group at >>>> http://groups.google.com/group/clojure?hl=en >>>> >>> >>> >>> >>> -- >>> On Clojure http://clj-me.cgrand.net/ >>> Clojure Programming http://clojurebook.com >>> Training, Consulting & Contracting http://lambdanext.eu/ >>> >>> >> >> >> -- >> On Clojure http://clj-me.cgrand.net/ >> Clojure Programming http://clojurebook.com >> Training, Consulting & Contracting http://lambdanext.eu/ >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
