avro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yang <teddyyyy...@gmail.com>
Subject Re: schema backward compatibility in RPC?
Date Thu, 26 May 2011 20:10:09 GMT
Doug:

thanks a lot.

I tried it again, yes it does work. The reason I thought it doesn't
work last time was, I actually tried the following code (modified from
the simple.avpr in source code):

{
   type: record, name:TestRecord, fields: [
         {name : msg, type: string },
         {name:  date, type:int}
   ]
}

messages: {
      echo : {
           request: [ { name: var1 , type: TestRecord } ]
           response: "TestRecord"
<=================================================== note here....
complex response type
     }
}


so the "echo" RPC call returns a TestRecord response, I actually got
errors on the return response parsing, if I change the protocol of the
client to change the "date" param to another one:  {name: signature ,
type: string }, then on the return value parsing, avro tries to insert
the value of "date" into the "signature" field, and gets a cast error.
I guess the schema resolution is done only on input params, and not on
return value?

if that's the case, then I think it probably makes sense, since the
return type is part of the method signature, and supposedly should not
change. and most likely in production, our use cases are that we
return only simple status codes, which can be encoded in int or string
types.  but I think there are other cases where the return value is a
complex structure, and in those cases, it probably is quite a trouble
if you have to create a new method name, simply because you added a
new field to your output param.

incidentally, I found that if I keep the name of an enum  type , but
add new enum values to it (at the end of the value list), and then use
the enum type as the return
type of my RPC call, it still works, although strictly speaking, the
enum type has already changed. but this is probably quite a dangerous
hack.


Thanks
Yang

On Thu, May 26, 2011 at 2:18 AM, Doug Cutting <cutting@apache.org> wrote:
> Yes, this is intended to work.  The client and server perform a
> handshake that ensures that each has the other's protocol.  Message
> parameters are treated as a record.  So, in your example, the server
> would ignore the date parameter.  If the server adds a parameter then it
> should supply a default value to its version of the protocol to allow
> for clients that do not supply this parameter.
>
> Doug
>
> On 05/24/2011 08:57 PM, Yang wrote:
>> I remember that Avro can handle schema changes, for example: when I
>> parse an incoming avro message, I can supply the known schema
>> associated with this message,
>> and the desired schema to parse it into.
>>
>>
>> but I wonder if this ability is automatically available in RPC too?
>>
>> for example , originally I define a remote call   echo() to be
>>
>> echo ( message {
>>                     date: integer,
>>                     content: string,
>>           }
>>         )
>>
>>
>> now the client still uses the old code, but server changes to
>>
>> echo ( message {
>>                     content: string
>>            }
>>      )
>>
>>
>> would that still work?  if so, I wonder where the server gets the
>> incoming schema?
>>
>> Thanks  a lot
>> Yang
>

Mime
View raw message