calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: Should Jackson-annotated POJOs stick around
Date Tue, 11 Aug 2015 20:14:26 GMT
Andrew Purtell wrote:
> That might be because protobuf documentation, and I'd assume accumulated
> practice based upon it, warns against using generated pbuf objects directly
> as model classes. (See the "Protocol Buffers and O-O Design" callout on

Assuming that's the case, that makes sense. It was just not clear to me 
if Julian and I were just talking past each other or if there was some 
fallacy I was suggesting.

> Maybe it's possible to wire up Jackson for emitting protobuf output as
> another transport option?

Thanks for the link. After Paul's offer of help, I meant to look around 
to see what this interaction would actually look like. I have more 
reading to do.

> On Tue, Aug 11, 2015 at 11:47 AM, Josh Elser<>  wrote:
>> >  I'll admit that I don't understand why protocol buffers is being equated
>> >  with the transport only.
>> >
>> >  The biggest reason I think Avatica can benefit from using software like
>> >  protobuf is that it makes handling a shift in the API substantially easier.
>> >  For example, what happens when a new field is added to a Request? What if
>> >  you receive a Request that doesn't have a field that you expected it to
>> >  (old client)? This is the problem that I'm trying to solve. Regardless of
>> >  whether this is coming in over the Java API or an HTTP connection, the
>> >  version of the Request or Response (and the actual attributes that it
>> >  contains) are near guaranteed to change.
>> >
>> >  I don't really care what the bytes look like going over the wire. That's
>> >  just a side-effect to which my only concern is to meet any desires for
>> >  readability that may exist.
>> >
>> >
>> >  Does that make sense?

View raw message