Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Duplicate
-
None
-
None
-
None
-
None
Description
These schemas are equivalent and should be fully compatible:
{"type": "record", "name": "Record1", "fields": [{"type": ["null", {"type": "array", "items": {"type": "record", "name": "InnerRecord1", "namespace": "ns2", "fields": [{"type": "int", "name": "a"}]}}], "name": "f1"}]} {"type": "record", "name": "Record1", "fields": [{"type": ["null", {"type": "array", "items": {"type": "record", "name": "ns2.InnerRecord1", "fields": [{"type": "int", "name": "a"}]}}], "name": "f1"}]}
(Note the way the full name is specified in the innerRecord1)
Currently schema compatibility between the two fails because the name attributes don't match. In this case the fullnames are identical.
In any case, the specification only needs to match the unqualified name. The following schema is not equivalent but should be compatible. Note the change in the namespace.
{"type": "record", "name": "Record1", "fields": [{"type": ["null", {"type": "array", "items": {"type": "record", "name": "ns3.InnerRecord1", "fields": [{"type": "int", "name": "a"}]}}], "name": "f1"}]}
It appears that the compatibility logic assumes that the name attribute has been unqualified.
Attachments
Issue Links
- is duplicated by
-
AVRO-3622 Python compatibility check fails if record with and without namespace are compared
- Resolved