| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Related 34cc301f03aea2e579d6687a9ea9782afc1089a0.
`QueryAttribute#value_for_database` calls only `type.serialize`, and
`Decimal#serialize` is a no-op unlike other attribute types.
Whether or not `serialize` will invoke `cast` is undefined in our test
cases, but it actually does not work properly unless it does so for now.
|
| | |
|
| |
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| | |
|
| |
|
|
| |
https://github.com/ruby/bigdecimal/pull/55
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Ruby 2.4, BigDecimal(), as used by the Decimal cast, was changed so
that it will raise ArgumentError when passed an invalid string, in order
to be more consistent with Integer(), Float(), etc. The other numeric
types use ex. to_i and to_f.
Unfortunately, we can't simply change BigDecimal() to to_d. String#to_d
raises errors like BigDecimal(), unlike all the other to_* methods (this
should probably be filed as a ruby bug).
Instead, this simulates the existing behaviour and the behaviour of the
other to_* methods by finding a numeric string at the start of the
passed in value, and parsing that using BigDecimal().
See also
https://bugs.ruby-lang.org/issues/10286
https://github.com/ruby/bigdecimal/commit/3081a627cebdc1fc119425c7a9f009dbb6bec8e8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now it behaves differently on JRuby:
```
--- expected
+++ actual
@@ -1 +1 @@
-#<BigDecimal:5f3c866c,'0.333333333333333333',18(20)>
+#<BigDecimal:16e0afab,'0.3333333333333333',16(20)>
```
My initial PR (https://github.com/rails/rails/pull/27324)
offered to let the precision to be decided by the platform and
change the test expection, but other contributors suggested
that we should change the default precision in Rails
to be consistent of all platforms.
The value (18) comes from the max default precision that comes
from casting Rational(1/3) to BigDecimal.
|
| |
|
|
|
|
|
|
|
| |
Recently, the Rails team made an effort to keep the source code consistent, using Ruboco
(bb1ecdcc677bf6e68e0252505509c089619b5b90 and below). Some of the case
statements were missed.
This changes the case statements' formatting and is consistent with changes
in 810dff7c9fa9b2a38eb1560ce0378d760529ee6b and db63406cb007ab3756d2a96d2e0b5d4e777f8231.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since precision is always larger than scale, it can actually change
rounding behavior. Given a precision of 5 and a scale of 3, when you
apply the precision of 5 to `1.25047`, the result is `1.2505`, which
when the scale is applied would be `1.251` instead of the expected
`1.250`.
This issue appears to only occur with floats, as scale doesn't apply to
other numeric types, and the bigdecimal constructor actually ignores
precision entirely when working with strings. There's no way we could
handle this for the "unknown object which responds to `to_d`" case, as
we can't assume an interface for applying the scale.
Fixes #24235
|
| |
|
|
|
|
|
| |
In Active Record, it appears these were either autoloaded, which
actually was likely due to test ordering since the method `Float#to_d`
wouldn't trigger it. This makes it explicit, and unlikely to fail in the
future.
|
|
|
The first step of bringing typecasting to ActiveModel
|
