compiler-segfault opened a new pull request, #12118:
URL: https://github.com/apache/arrow-rs/pull/12118

   # Which issue does this PR close?
   
   - Closes #11960
   
   # Rationale for this change
   
   A nested named type without a `namespace` attribute inherits the namespace of
   the enclosing named type (Avro spec, "Names"), so the same type can be 
written
   as `{"name": "Bw", "namespace": "ns"}` by one producer and as `{"name": 
"Bw"}`
   inside a record in `ns` by another. When a reader schema is supplied, `Maker`
   compares record, enum and fixed names with each type's own `namespace`
   attribute only, so those two forms are treated as different names and the
   schema is rejected:
   
   ```text
   Record name mismatch writer=Bw, reader=Bw
   ```
   
   `apache-avro` writes the inherited namespace explicitly on every nested named
   type, so files it writes cannot be read with the schema the user wrote. When
   the nested record is a union branch, the branch is also left unmapped and
   decoding fails with `Union branch index 1 not resolvable by reader schema`.
   
   # What changes are included in this PR?
   
   `resolve_records`, `resolve_enums` and `resolve_fixed` resolve each side's
   namespace with the existing `named_type_namespace` helper, which takes the
   enclosing namespace into account, and compare those full names.
   
   # Are these changes tested?
   
   Yes. Two regression tests in `codec.rs` build writer/reader schema pairs that
   differ only in whether the inherited namespace is written out, for a plain
   field and for a union branch. Both fail on `main` with the mismatch above and
   pass with the change. `cargo test -p arrow-avro --lib codec::` passes (52
   tests) and `cargo clippy -p arrow-avro --all-targets -- -D warnings` is 
clean.
   
   # Are there any significant user-facing changes?
   
   No.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to