Details
-
Bug
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
None
Description
A schema with a field that is a ref to a different schema is incompatible with itself, per `SchemaCompatibility`:
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);
}
}
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`.
Attachments
Issue Links
- links to
