Move integer range validation to never raise on assignment

Given that this was originally added to normalize an error that would
have otherwise come from the database (inconsistently), it's more
natural for us to raise in `type_cast_for_database`, rather than
`type_cast_from_user`. This way, things like numericality validators can
handle it instead if the user chooses to do so. It also fixes an issue
where assigning an out of range value would make it impossible to assign
a new value later.

This fixes several vague issues, none of which were ever directly
reported, so I have no issue number to give. Places it was mentioned
which I can remember:

- https://github.com/thoughtbot/shoulda-matchers/blob/9ba21381d7caf045053a81f32df7de2f49687820/lib/shoulda/matchers/active_model/allow_value_matcher.rb#L261-L263
- https://github.com/rails/rails/issues/18653#issuecomment-71197026

1 files changed, 8 insertions, 0 deletions

diff --git a/activerecord/CHANGELOG.md b/activerecord/CHANGELOG.md
index 2054c9573e..22b1c8e95b 100644
--- a/activerecord/CHANGELOG.md
+++ b/activerecord/CHANGELOG.md
@@ -1,3 +1,11 @@
+*   Integer types will no longer raise a `RangeError` when assigning an
+    attribute, but will instead raise when going to the database.
+
+    Fixes several vague issues which were never reported directly. See the
+    commit message from the commit which added this line for some examples.
+
+    *Sean Griffin*
+
 *   Values which would error while being sent to the database (such as an
     ASCII-8BIT string with invalid UTF-8 bytes on Sqlite3), no longer error on
     assignment. They will still error when sent to the database, but you are