avro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joseph P." <joseph.pac...@gmail.com>
Subject Re: Implementation of compatibility rules
Date Wed, 22 Feb 2017 16:47:58 GMT
This change (considering alias in schema compatibility) is really welcomed
and needed in our usage of it. So thanks a lot for this much needed change
(IMHO).

best,
joseph

On Wed, Feb 22, 2017 at 4:55 PM, Elliot West <teabot@gmail.com> wrote:

> Update:
>
> I had a go at modifying org.apache.avro.SchemaValidatorBuilder to use
> SchemaCompatibility and have then run schema compatibility test suites
> from both the Avro project and Confluent's Schema registry. Every case that
> is tested appears to continue to function correctly with one exception;
> SchemaCompatibility appears to favourably consider aliases when
> performing name based compatibility checks whereas the implementation
> provided via SchemaValidatorBuilder is more strict, and does not.
>
> The specification <http://avro.apache.org/docs/1.8.1/spec.html#Aliases>
> makes no definitive judgement on the matter, simply stating that 'an
> implementation may optionally use aliases'. Should perhaps this be
> configurable in the aforementioned implementations so that the user can
> decide and also have a chance of obtaining consistent behaviour?
>
> Elliot.
>
> On 22 February 2017 at 13:48, Elliot West <teabot@gmail.com> wrote:
>
>> Further to this, is there any reason why conceptually, the implementation
>> of org.apache.avro.ValidateMutualRead.canRead(Schema, Schema) could not
>> be changed from:
>>
>>   static void canRead(Schema writtenWith, Schema readUsing)
>>       throws SchemaValidationException {
>>     boolean error;
>>     try {
>>       error = Symbol.hasErrors(new ResolvingGrammarGenerator().generate(
>>           writtenWith, readUsing));
>>     } catch (IOException e) {
>>       throw new SchemaValidationException(readUsing, writtenWith, e);
>>     }
>>     if (error) {
>>       throw new SchemaValidationException(readUsing, writtenWith);
>>     }
>>   }
>>
>>
>> to:
>>
>>   static void canRead(Schema writtenWith, Schema readUsing)
>>       throws SchemaValidationException {
>>     SchemaCompatibilityType compatibilityType
>>       = SchemaCompatibility.checkReaderWriterCompatibility(readUsing,
>> writtenWith).getType();
>>     if (compatibilityType != SchemaCompatibilityType.COMPATIBLE) {
>>       throw new SchemaValidationException(readUsing, writtenWith);
>>     }
>>   }
>>
>>
>> Or am I missing something fundamental?
>>
>> Thanks,
>>
>> Elliot.
>>
>> On 17 February 2017 at 12:27, Elliot West <teabot@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I've been attempting to understand the implementation of Avro schema
>>> compatibility rules and am slightly confused by the structure of the code.
>>> It seems that there are at least two possible entry points:
>>>
>>>    - org.apache.avro.SchemaCompatibility.checkReaderWriterCompatibility(Schema,
>>>    Schema)
>>>    - org.apache.avro.SchemaValidatorBuilder
>>>
>>> The code paths of these do not seem to intersect, with one implementing
>>> a static set of rule checks and the other seemingly delegating to grammar
>>> based approach. Does this imply that there are in fact two implementations
>>> of the compatibility rules?
>>>
>>> Apologies if this is a naïve question.
>>>
>>> Thanks,
>>>
>>> Elliot.
>>>
>>
>>
>

Mime
View raw message