calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Should Jackson-annotated POJOs stick around
Date Tue, 11 Aug 2015 20:21:07 GMT
Watching CALCITE-840 with interest.


On Tue, Aug 11, 2015 at 1:14 PM, Josh Elser <josh.elser@gmail.com> wrote:

> 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
>> https://developers.google.com/protocol-buffers/docs/javatutorial.)
>>
>
> 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?
>> https://github.com/FasterXML/jackson-dataformat-protobuf
>>
>
> 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<josh.elser@gmail.com>  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?
>>>
>>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message