public/schema: add Decimal common type with precision and scale#420
Merged
Conversation
Introduces a new Decimal CommonType carrying its precision and scale via a LogicalParams struct, enabling lossless schema conversion across Avro, Parquet, and database NUMBER/NUMERIC decimals. Bounds (precision in [1, 38], scale in [0, precision]) describe the lossless intersection of the targeted downstream formats. Adds NewDecimal, FormatDecimal/ParseDecimal, and DecimalParams.Format / Parse / ValidateValue helpers so data sources and converters share a single canonical-string contract. Also adds Common.Validate as the public entry point for schema-parameter checks; ParseFromAny now validates once at the top level rather than O(depth) times. Documents the schema changes and the converter/data-source contracts in public/schema/decimal_types.md.
| return 0, fmt.Errorf("missing field `%s`", key) | ||
| } | ||
|
|
||
| switch n := v.(type) { |
Contributor
There was a problem hiding this comment.
Do we need to handle json.Number in the case statement below as well?
Collaborator
Author
There was a problem hiding this comment.
Excellent catch, @josephwoodward — addressed in d1e0b1a. anyIntField now handles json.Number via Int64(), and a sweep turned up a sibling gap in InferFromAny (any caller piping values through json.Decoder.UseNumber() would have hit unsupported data type for every numeric value), which now classifies json.Number as Int64 when it parses as an integer and Float64 otherwise. End-to-end coverage exercises the full ToAny -> json.Marshal -> Decoder.UseNumber -> ParseFromAny round-trip.
josephwoodward
approved these changes
Apr 28, 2026
Adds json.Number handling to anyIntField (used for decimal precision and scale parsing in ParseFromAny) and to InferFromAny. Without this, schemas pipelined through a json.Decoder configured with UseNumber lose round-trip fidelity at the parsing boundary. InferFromAny classifies json.Number as Int64 when it parses as an integer and Float64 otherwise. Adds an end-to-end test exercising the ToAny -> json.Marshal -> Decoder.UseNumber -> ParseFromAny path.
josephwoodward
approved these changes
Apr 28, 2026
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Decimalcommon type topublic/schema, parameterised by precision and scale via a newLogicalParamsstruct so the existing common schema can describe fixed-precision decimals losslessly across Avro, Parquet, and databaseNUMBER/NUMERICcolumns.precision ∈ [1, 38],scale ∈ [0, precision]) describe the lossless intersection of the targeted downstream formats. Oracle's negative-scale and unbounded-precision variants do not survive Avro/Parquet round-trips and are therefore not modelled.NewDecimal,FormatDecimal/ParseDecimal, andDecimalParams.Format/Parse/ValidateValue. These codify the canonical-string value contract so every data-source plugin and converter shares a single formatter rather than reinventing it.Common.Validateas the public entry point for schema-parameter checks.ParseFromAnynow validates once at the top level instead ofO(depth)times.mysql_cdc,oracle_cdc, etc.) inpublic/schema/decimal_types.md.Non-decimal schemas keep their existing fingerprints byte-for-byte, so any cached conversions keyed on fingerprint remain valid.
Test plan
task fmttask lint(0 issues)task test(full repo suite passes)Decimalparse/serialise round-trips, validation rules, fingerprint sensitivity to precision and scale, and helper round-trip property