[ 
https://issues.apache.org/jira/browse/AVRO-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17842072#comment-17842072
 ] 

ASF subversion and git services commented on AVRO-3974:
-------------------------------------------------------

Commit cd3e2dfa2cbb7648abe5d7222ab7f6424da83c43 in avro's branch 
refs/heads/dependabot/maven/lang/java/org.apache.hadoop-hadoop-client-3.4.0 
from Martin Grigorov
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=cd3e2dfa2 ]

AVRO-3974: [Rust] Support schema compatibility for Schema::Ref (#2847)

Signed-off-by: Martin Tzvetanov Grigorov <mgrigo...@apache.org>

> [Rust] incorrect compatibility checks with ref fields
> -----------------------------------------------------
>
>                 Key: AVRO-3974
>                 URL: https://issues.apache.org/jira/browse/AVRO-3974
>             Project: Apache Avro
>          Issue Type: Bug
>          Components: rust
>            Reporter: mknaw
>            Assignee: Martin Tzvetanov Grigorov
>            Priority: Minor
>              Labels: pull-request-available
>             Fix For: 1.12.0, 1.11.4
>
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> A schema with a field that is a ref to a different schema is incompatible 
> with itself, per `SchemaCompatibility`:
> {code:java}
> use apache_avro::{schema_compatibility::SchemaCompatibility, Schema};
> fn main() {
>     let schema_strs = vec![
>         r#"{
>           "type": "record",
>           "name": "Child",
>           "namespace": "avro",
>           "fields": [
>             {
>               "name": "val",
>               "type": "int"
>             }
>           ]
>         }
>         "#,
>         r#"{
>           "type": "record",
>           "name": "Parent",
>           "namespace": "avro",
>           "fields": [
>             {
>               "name": "child",
>               "type": "avro.Child"
>             }
>           ]
>         }
>         "#,
>     ];
>     
>     let schemas = Schema::parse_list(&schema_strs).unwrap();
>     if let Err(e) = SchemaCompatibility::can_read(
>         &schemas[1],
>         &schemas[1]
>     ) {
>         eprintln!("{}", e);
>     }
> } {code}
>  
> Here it is somewhat ambiguous to me how the fix should look. of course the 
> simplest (and already an improvement over the current state) is just to 
> verify the names are the same, and maybe it's assumed callers doing compat 
> checks across a batch will check the compat of the referenced schema 
> separately from the referencing schema. But this isn't quite satisfactory - 
> imagine having a complex field that was previously defined inline, but now 
> want to reuse it across multiple schemas. In this case, it does not seem like 
> replacing the inline definition with a ref should be incompatible. So, it 
> seems that some sort of "recursive flattening" of the schema prior to compat 
> check would be the ideal fix. Or, maybe, the compat check just checks on 
> names, but callers who want this behavior can do some (new?) "flattening" 
> operation on some schema among `ResolvedSchema`, and then use that as the 
> argument for compat checks.
> This appears to be the case both on `main` at the time of writing 
> (`00afbaed`) and `0.16.0`.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to