thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Slee <ms...@facebook.com>
Subject RE: Idea: Validations
Date Tue, 28 Oct 2008 17:54:38 GMT
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

Mime
View raw message