Repository navigation
Conversation
…rmat DecimalCodec.EncodeDecimal wrote coefficients with more digits than the format allows, and exponents outside its range, without any check (only a Debug.Assert). In Release builds the excess bits overflowed into the combination/exponent fields and the server stored a different value, e.g.: 12345678901234567890123456789012345 -> DECFLOAT(34) stored 8345678901234567890123456789012345 30000000000000004E-17 -> DECFLOAT(16) stored 0.08000000000000004 1E400 -> DECFLOAT(16) stored 8.000000000000001E-353 The encoder now brings the value into the format's ranges without changing its numeric value (dropping trailing zeros of the coefficient, folding the exponent into the coefficient, clamping the exponent of zero), and throws OverflowException when the value cannot be represented exactly (too many significant digits, exponent overflow or underflow). Values that previously got corrupted although representable (e.g. 1E384 in DECFLOAT(16)) now work.
The conversions formatted the value with a fixed custom format and then
removed the decimal point, assuming one was present. This threw
ArgumentOutOfRangeException for every value without a fractional part,
e.g. (FbDecFloat)1m, (FbDecFloat)100m, (FbDecFloat)2.0, and for values
smaller than the format's decimal places, e.g. (FbDecFloat)1e-20. It also
dropped the scale of decimals (1.10m became 1.1) and digits beyond 15
decimal places of doubles (7 for floats).
- decimal: converted exactly from its 96-bit integer and scale, so the
value and its scale are preserved (1.10m -> 110E-2), including -0.
- double/float: converted to the shortest decimal that round-trips to the
same binary value ("R" format), e.g. 0.1 -> 1E-1, 0.1 + 0.2 ->
30000000000000004E-17, 1e-20 -> 1E-20; -0.0 -> negative zero.
A converted double may have up to 17 significant digits; sending it to a
DECFLOAT(16) throws OverflowException instead of being silently rounded
(this relies on the encoder range check of the previous commit).
Random.NextInt64() never returns a negative value, so the random doubles were all positive. Use the full long range and assert both signs are covered.
Parameters: a DECFLOAT parameter only accepted FbDecFloat; any other value (decimal, double, int, ...) threw InvalidCastException, even when the parameter was created by AddWithValue with a decimal. Values of type decimal, double, float, the integral types and BigInteger are now converted to FbDecFloat (decimal exactly, double/float to the shortest round-trip value). A value that does not fit the DECFLOAT precision exactly throws OverflowException instead of being rounded. Reader: GetDecimal, GetDouble, GetFloat, GetInt16/32/64 and GetByte (and the matching GetFieldValue<T>) on a DECFLOAT column threw InvalidCastException because FbDecFloat is not IConvertible. Now: - GetDecimal: exact, keeping the scale (1.10 -> 1.10m); OverflowException when the value cannot be represented exactly (too large, too many digits, NaN, infinity). - GetDouble/GetFloat: nearest value, like on NUMERIC columns; NaN and infinities are mapped, out-of-range values become infinity or zero. - Integer getters: nearest integer, ties to even, as Convert does for decimal columns; OverflowException when out of range, NaN or infinity. FbDecFloat gets the matching public explicit conversions to decimal, double and float.
- Provider: add net11.0 to TargetFrameworks. No Microsoft.Extensions.Logging.Abstractions package reference is needed for net11.0: the assembly ships in the .NET 11 shared framework, and NuGet prunes the reference (the nuspec net11.0 group is empty). - Tests: multi-target FirebirdSql.Data.FirebirdClient.Tests to net10.0;net11.0 so TFM-specific code paths are exercised on both. - tests.ps1: copy the Firebird binaries into, and run the FirebirdClient suites from, every provider test TFM output. - CI: install the .NET 11 SDK (preview quality until 11.0 GA).
.NET 11 introduces the IEEE 754 decimal floating-point types Decimal32, Decimal64 and Decimal128. Their decimal interchange encoding (EncodeDecimal/DecodeDecimal, densely packed decimal) is the encoding of Firebird's DECFLOAT(16)/DECFLOAT(34): the provider's DECFLOAT codec and .NET agree bit for bit (asserted by a seeded test over random values and all special values), so the conversions are exact, including the exponent (1.10 stays 1.10), negative zero, infinities and NaNs, with no text round trip. On net11.0 only: - FbDecFloat: explicit conversions from Decimal32/Decimal64/Decimal128 (exact) and to Decimal64/Decimal128 (exact, OverflowException when the value does not fit). - Parameters: Decimal128 values infer FbDbType.Dec34, Decimal64 and Decimal32 infer FbDbType.Dec16. They can be passed to any numeric parameter; a value that does not fit the target exactly (e.g. a 34-digit Decimal128 into DECFLOAT(16)) throws OverflowException instead of being rounded. - Reader: GetFieldValue<Decimal128>() and GetFieldValue<Decimal64>() for DECFLOAT and the other numeric types (exact, OverflowException when the value does not fit). GetValue()/GetFieldType() still return FbDecFloat for DECFLOAT columns.
Every parameter value reaches DbValue through FbParameter.InternalValue (FbCommand and FbBatchCommand, sync and async), so Decimal32/64/128 values are converted to FbDecFloat there. DbValue no longer checks the type of every value it stores: both clients store decoded row values in DbValue (the managed client through the constructors, the native client through SetValue), and those values are never IEEE decimals. DbValue's constructors and SetValue are back to their previous code. Adds a batch command test (Decimal64/Decimal128 parameters, bit-exact round trip), as FbBatchCommand takes the same path.
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
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.
Part of #1302. Based on #1307 and #1303.
Summary
On
net11.0, the .NET 11 IEEE 754 decimal typesDecimal32,Decimal64andDecimal128can be used with DECFLOAT. Existing behavior is unchanged.Their decimal interchange encoding (
EncodeDecimal/DecodeDecimal, densely packed decimal) is the DECFLOAT wire encoding: the provider'sDecimalCodecand .NET agree bit for bit. So all conversions are exact and go through the existing codec, with no text round trip.Changes (all under
#if NET11_0_OR_GREATER)FbDecFloat: explicit conversions fromDecimal32/Decimal64/Decimal128, which are exact, and toDecimal64/Decimal128, which are exact or throwOverflowExceptionwhen the value has too many digits or its exponent is out of range.TypeHelper.GetFbDataTypeFromType:Decimal128maps toFbDbType.Dec34;Decimal64andDecimal32map toFbDbType.Dec16.FbParameter.InternalValue, through which every parameter value reachesDbValue(FbCommandandFbBatchCommand, sync and async), converts IEEE decimal values toFbDecFloat, so every existing conversion handles them. ADecimal128sent toDECFLOAT(16)works when it fits exactly and throws otherwise. Decoding rows is untouched:DbValue's constructors andSetValueare unchanged.DbValue: addsGetDecimal128andGetDecimal64.FbDataReader.GetFieldValue<Decimal128>and<Decimal64>(sync and async), for DECFLOAT and the other numeric types.GetValue/GetFieldTypestill returnFbDecFloat; see Add DecFloat Type connection option to return DECFLOAT as Decimal64/Decimal128 #1309 for the opt-in.Tests (net11.0 only)
FbDecFloatIeee754Tests(NoServer):Decimal64/Decimal128.EncodeDecimalagree bit for bit, and the conversions keep the coefficient and exponent,FbDecimalIeee754SupportTests:Decimal64/Decimal128, bit-exact for limits, cohort, -0 and ±Inf; NaN and sNaN read as NaN,Decimal64from DECFLOAT(34): exact, or throws,Decimal128,Decimal128/Decimal64/Decimal32parameters: type inference, bit-exact round trip, and narrowing that throws while the connection stays usable,FbBatchCommandTests(managed client only, like the other batch tests):Decimal64/Decimal128batch parameters, bit-exact round trip. Verified locally against Firebird 5.0.4 with a probe that does the same:AllSuccess=True, both rows bit-exact.Known gap (follow-up)
Combined with #1305,
GetFieldValue<Decimal128>()on a NUMERIC(38) value beyondSystem.Decimalthrows, even when the value has 34 digits or fewer. Verified on a merge of both branches, embedded client:Whichever of the two PRs is merged second can add the
BigDecimalcase toDbValue.GetDecFloat.