Idea: Validations

[Bryan Duxbury <br...@rapleaf.com>]

I was thinking today about how it would be useful to have some the  
option to do some kinds of validations on field values in Thrift  
objects. For instance, say you have a struct with a field "required  
string blah". You've managed to specify that it must be part of the  
struct, but nothing else. What if you also want to demand that it's a  
non-empty string? Or if it needs to be of a certain length? These are  
things that would make the generated code a lot more convenient to  
use at times.

There are potentially a lot of these validations you could create,  
but most of them would be pretty trivial to implement in multiple  
languages. String, byte[], and collection length would be one simple  
one. Greater/less than for numeric fields would be another. One  
potentially tricky but awesome one would be "must match regex"  
validation on string fields.

Clearly these validations might have a performance implication, so  
you probably wouldn't expect the to be run by default on all structs,  
though it'd be sensible to be able to enable and disable them  
globally so you can switch from development to production mode  
easily. You could always have access to the functionality via a  
public validate() method that would tell you true or false if the  
struct contained the proper fields.

Do others think this would be interesting? It'd potentially introduce  
a lot of work in making sure each different validation was  
implemented across languages, but that would be mitigated by not  
having to have your application developers write the validation code  
in all the languages you use.

-Bryan

Re: Idea: Validations

[Ted Dunning <te...@gmail.com>]

Sounds interesting.

On Mon, Oct 27, 2008 at 6:34 PM, Bryan Duxbury <br...@rapleaf.com> wrote:

> I was thinking today about how it would be useful to have some the option
> to do some kinds of validations on field values in Thrift objects. For
> instance, say you have a struct with a field "required string blah". You've
> managed to specify that it must be part of the struct, but nothing else.
> What if you also want to demand that it's a non-empty string? Or if it needs
> to be of a certain length? These are things that would make the generated
> code a lot more convenient to use at times.
>
> There are potentially a lot of these validations you could create, but most
> of them would be pretty trivial to implement in multiple languages. String,
> byte[], and collection length would be one simple one. Greater/less than for
> numeric fields would be another. One potentially tricky but awesome one
> would be "must match regex" validation on string fields.
>
> Clearly these validations might have a performance implication, so you
> probably wouldn't expect the to be run by default on all structs, though
> it'd be sensible to be able to enable and disable them globally so you can
> switch from development to production mode easily. You could always have
> access to the functionality via a public validate() method that would tell
> you true or false if the struct contained the proper fields.
>
> Do others think this would be interesting? It'd potentially introduce a lot
> of work in making sure each different validation was implemented across
> languages, but that would be mitigated by not having to have your
> application developers write the validation code in all the languages you
> use.
>
> -Bryan
>



-- 
ted

RE: Idea: Validations

[Mark Slee <ms...@facebook.com>]

I think it's generally an interesting idea but it definitely strays into
the gray area of mixing application functionality with
transport/protocol functionality. A main concern is definitely
implementation coverage across languages. I'd definitely want to avoid
getting into things like regex matching here. It's also unclear if there
would always be one standard way in which clients would want to handle
these errors. Leaving this in the application code lets you take
appropriate action for the error on a case-by-case basis, whereas
building this into Thrift would require one exception/error model for
handling these.

This also sounds like a good use case for the custom modifier extensions
that dreiss has been working on.

Cheers,
mcslee

-----Original Message-----
From: Bryan Duxbury [mailto:bryan@rapleaf.com] 
Sent: Monday, October 27, 2008 6:35 PM
To: thrift-user@incubator.apache.org
Subject: Idea: Validations

I was thinking today about how it would be useful to have some the
option to do some kinds of validations on field values in Thrift
objects. For instance, say you have a struct with a field "required
string blah". You've managed to specify that it must be part of the
struct, but nothing else. What if you also want to demand that it's a
non-empty string? Or if it needs to be of a certain length? These are
things that would make the generated code a lot more convenient to use
at times.

There are potentially a lot of these validations you could create, but
most of them would be pretty trivial to implement in multiple languages.
String, byte[], and collection length would be one simple one.
Greater/less than for numeric fields would be another. One potentially
tricky but awesome one would be "must match regex"  
validation on string fields.

Clearly these validations might have a performance implication, so you
probably wouldn't expect the to be run by default on all structs, though
it'd be sensible to be able to enable and disable them globally so you
can switch from development to production mode easily. You could always
have access to the functionality via a public validate() method that
would tell you true or false if the struct contained the proper fields.

Do others think this would be interesting? It'd potentially introduce a
lot of work in making sure each different validation was implemented
across languages, but that would be mitigated by not having to have your
application developers write the validation code in all the languages
you use.

-Bryan