Hi Yoel,

I have reproduced the problem with your sample code. The schemas you pasted
in this thread are fine. But if we embed them into an union, the problem
happens.

I have created https://issues.apache.org/jira/browse/AVRO-1883 to track
this problem.

*Yibing Shi*
*Customer Operations Engineer*
<http://www.cloudera.com>

On Wed, Jul 13, 2016 at 12:15 AM, Yoel Amram <[email protected]>
wrote:

> Hi,
>
>
>
> It seems that backward compatibility for schemas composed of union of
> record types is not working as expected.
>
>
>
> I have these 2 schemas:
>
>
>
> Schema1:
>
> [
>    {
>       *"type"*:"record",
>       *"name"*:"rec1",
>       *"fields"*:[
>          {
>             *"name"*:"age",
>             *"type"*:"long"
>          }
>       ]
>    },
>    {
>       *"type"*:"record",
>       *"name"*:"rec2",
>       *"fields"*:[
>          {
>             *"name"*:"username",
>             *"type"*:"string"
>          }
>       ]
>    }
> ]
>
>
>
> Schema2:
>
> [
>    {
>       *"type"*:"record",
>       *"name"*:"rec1",
>       *"fields"*:[
>          {
>             *"name"*:"age",
>             *"type"*:"long"
>          },
>          {
>             *"name"*:"address",
>             *"type"*:"string"
>          }
>       ]
>    },
>    {
>       *"type"*:"record",
>       *"name"*:"rec2",
>       *"fields"*:[
>          {
>             *"name"*:"username",
>             *"type"*:"string"
>          }
>       ]
>    }
> ]
>
>
>
> when validating schema2 against schema1 it passes while I would expect it
> to fail with SchemaValidationException as ‘rec1’ in schema2 was added a new
> non optional field (marked in red).
>
>
>
> The code I’m using for the test is attached (using version 1.8.1), note
> that when I replace schemas with the commented lines – validation fails
> (these ones contains the same rec1 record type without union).
>
>
>
> Is this a bug in the way backward compatibility is validated for union
> types?
>
>
>
> Thanks.
>
>
>
>
> This communication (including any attachments) is sent on behalf of
> Playtech plc or one of its subsidiaries (Playtech Group). It contains
> information which is confidential and privileged. If you are not the
> intended recipient, please notify the sender immediately and destroy any
> copies of this communication. Unless expressly stated to the contrary,
> nothing in this communication constitutes a contractual offer capable of
> acceptance or indicates intention to create legal relations or grant any
> rights. The Playtech Group monitors communications sent or received by it
> for security and other purposes. Any views or opinions presented are solely
> those of the author and do not necessarily represent those of the Playtech
> Group
>

Reply via email to