GeezerVison

Description

DecimalParameter.calculate_decimal_cast_string (parameters/native.py) infers the DECIMAL(precision, scale) to cast a bound Decimal to by string-splitting str(value) on ".". That miscounts two forms str(Decimal) legitimately produces, so the generated type can't hold the bound value.

Exponent notation — str() emits E for many magnitudes (e.g. Decimal("1500").normalize() is Decimal("1.5E+3"); .scaleb(), arithmetic, and scientific input do the same):

cursor.execute("SELECT ?", [Decimal("1500").normalize()])
# infers DECIMAL(5,4)  -- the "E+3" is counted as 4 fractional digits
# but 1500 needs DECIMAL(4,0); DECIMAL(5,4) max is ±9.9999 -> overflow
#   -> error in ANSI mode, or silently NULL in legacy mode

Negative values — the leading - is counted as an integer digit, over-widening every negative by one precision digit, which becomes a hard failure at the boundary:

Decimal("-" + "9" * 38)   # a valid DECIMAL(38,0)
# infers DECIMAL(39,0), which exceeds Databricks' maximum DECIMAL precision of 38
#   -> invalid cast, query fails

Both the cast type and the bound literal come from the same value, so the server can't reconcile them — a perfectly valid Decimal is rejected or silently nulled.

Fix

Derive precision/scale from Decimal.as_tuple() (sign, digits, exponent) — the exact numeric value — instead of the display string, so sign and exponent formatting no longer inflate the counts. Handles exponent notation, negatives, and sub-1 values uniformly.

Tests

The six existing test_calculate_decimal_cast_string cases are unchanged and still pass. Added regression cases for exponent notation (Decimal("1500").normalize() → DECIMAL(4,0), Decimal("1e5") → DECIMAL(6,0)) and negatives (-9…9 (38 digits) → DECIMAL(38,0), Decimal("-12.34") → DECIMAL(4,2)). tests/unit/test_parameters.py passes (60).