Fix avro bugs - #745
Conversation
There was a problem hiding this comment.
Class name should follow naming convention, no underscores.
There was a problem hiding this comment.
this is a pre-existing class - do you want me to rename the file?
There was a problem hiding this comment.
I renamed the class but there are other classes in this repo that have this non-standard naming
There was a problem hiding this comment.
Ah sorry, did not realize. Thank you for renaming, going forward will try to keep an eye on additions.
|
Looks good, but does require entry in (or ideally more specific -- but something) |
Added an entry to VERSION file - this PR is targeted at 3.x so I added the entry under 3.3.0. |
|
Hmmh. Claude found many issues here, will need to massage a bit... |
… default precision (#754)
Claude AI found these - they look plausible to me but I must admit to not being an Avro expert.
Fix 1: _resolveBigDecimalIndex — dead code / wrong union branch
AvroWriteContext.java:441-448 — The second if (t == Type.DOUBLE) was dead code (unreachable after the first). The intent was to prefer STRING/BYTES (which preserve BigDecimal precision via logical types) and fall back to DOUBLE. Fixed to check STRING and BYTES first, with DOUBLE as the fallback match.
Fix 2: Stale type variable in both _createRecord overloads
AvroWriteContext.java:157-168, 179-195 — Both overloads captured type before union resolution but never updated it afterward. The MAP guard checked the stale type (still UNION) and would never trigger if the resolved schema was a MAP. Fixed by re-reading type = schema.getType() after union resolution.
Fix 3: Integer defaults stored as float — precision loss
AvroFieldDefaulters.java:31-38 — VALUE_NUMBER_INT cases used FloatDefaults (24-bit mantissa), silently losing precision for int values > 16,777,216 and all long values. IntDefaults and LongDefaults already existed in ScalarDefaults.java but were unused. Fixed to use IntDefaults for INT and LongDefaults for LONG/BIG_INTEGER.