| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Why are people assigning booleans to string columns? >_>
We unintentionally changed the behavior on Sqlite3 and PostgreSQL.
Boolean values should cast to the database's representation of true and
false. This is 't' and 'f' by default, and "1" and "0" on Mysql. The
implementation to make the connection adapter specific behavior is hacky
at best, and should be re-visted once we decide how we actually want to
separate the concerns related to things that should change based on the
database adapter.
That said, this isn't something I'd expect to change based on my
database adapter. We're storing a string, so the way the database
represents a boolean should be irrelevant. It also seems strange for us
to give booleans special behavior at all in string columns. Why is
`to_s` not sufficient? It's inconsistent and confusing. Perhaps we
should consider deprecating in the future.
Fixes #17571
|
|
|
|
|
| |
We had accidentally gone one power of two too far. In addition, we need
to handle minimum values as well as the maximum.
|
|
|
|
|
|
|
|
|
|
|
| |
Sufficiently large integers cause `find` and `find_by` to raise
`StatementInvalid` instead of `RecordNotFound` or just returning `nil`.
Given that we can't cast to `nil` for `Integer` like we would with junk
data for other types, we raise a `RangeError` instead, and rescue in
places where it would be highly unexpected to get an exception from
casting.
Fixes #17380
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch uniformizes warning messages. I used the most common style
already present in the code base:
* Capitalize the first word.
* End the message with a full stop.
* "Rails 5" instead of "Rails 5.0".
* Backticks for method names and inline code.
Also, converted a few long strings into the new heredoc convention.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In Rails 5.0, we'd like to change the behavior of boolean columns in
Rails to be closer to Ruby's semantics. Currently we have a small set
of values which are "truthy", and all others are "falsy". In Rails 5.0,
we will reverse this to have a small number of values which are "falsy",
and all others will become "truthy".
In the interim, all values which are ambiguous must emit a deprecation
warning.
|
| |
|
|
|
|
| |
Fixes #16701
|
|
|
|
|
| |
This was a small self contained piece of the refactoring that I am
working on, which required these objects to be comparable.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
joker1007/fix_decimal_cast_from_float_with_large_precision
Fix type casting to Decimal from Float with large precision
Conflicts:
activerecord/CHANGELOG.md
|
| |
| |
| |
| |
| | |
When I defines large precision column at RDBMS,
I assigns float value, raise ArgumentError (precision too large).
|
|/
|
|
| |
Ruby generally does not use the is_* prefix on predicate methods.
|
|
|
|
|
| |
One of the branches is using a proc to check if the value respond_to a
method so it is better to not do case comparations
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This was only used for uniqueness validations. The first usage was in
conjunction with `limit`. Types which cast to string, but are not
considered text cannot have a limit. The second case was only with an
explicit `:case_sensitive => true` option given by the user.
|
| |
|
| |
|
|\
| |
| |
| | |
Detect in-place modifications on Strings
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
We previously only did this if the old value was zero, to make sure
numericality validations run and failed if the user gave 'wibble' as the
value, which would be type cast to 0. However, numericality validations
will fail if there are any non-numeric characters in the string, so 5 ->
'5wibble' should also be marked as changed.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Adding `# :nodoc:` to the parent `class` / `module` is not going
to ignore nested classes or modules.
There is a modifier `# :nodoc: all` but sadly the containing class
or module will continue to be in the docs.
/cc @sgrif
|
| | |
|
|/
|
|
|
|
|
| |
`Type::Integer.new.type_cast('') # => nil`, we do not need a special
case to handle this, `nil => ''` already returns false. The only case we
need to handle is `0 => 'wibble'` should be changed, while `0 => '0'`
should not.
|
|
|
|
|
|
|
|
|
| |
The case where we have a column object, but don't have a type cast
method involves type casting the default value when changing the schema.
We get one of the column definition structs instead. That is a case that
I'm trying to remove overall, but in the short term, we can achieve the
same behavior without needing to pass the adapter to the array type by
creating a fake type that proxies to the adapter.
|
| |
|
|
|
|
|
|
| |
We have several mutable types on Active Record now. (Serialized, JSON,
HStore). We need to be able to detect if these have been modified in
place.
|
|
|
|
|
| |
On MySQL and PostgreSQL, the adapter does not type cast virtual columns
for us.
|
|
|
|
|
|
|
|
| |
In some cases there is a difference between the two, we should always
be doing one or the other. For convenience, `type_cast` is still a
private method on type, so new types that do not need different behavior
don't need to implement two methods, but it has been moved to private so
it cannot be used accidentally.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- The following is now true for all types, all the time
- `model.attribute_before_type_cast == given_value`
- `model.attribute == model.save_and_reload.attribute`
- `model.attribute == model.dup.attribute`
- `model.attribute == YAML.load(YAML.dump(model)).attribute`
- Removes the remaining types implementing `type_cast_for_write`
- Simplifies the implementation of time zone aware attributes
- Brings tz aware attributes closer to being implemented as an attribute
decorator
- Adds additional point of control for custom types
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The definition of `write_attribute` in dirty checking ultimately leads
to the columns calling `type_cast` on the value to perform the
comparison. However, this is a potentially expensive computation that we
cache when it occurs in `read_attribute`. The only case that we need the
non-type-cast form is for numeric, so we pass that through as well
(something I'm looking to remove in the future).
This also reduces the number of places that manually access various
stages in an attribute's type casting lifecycle, which will aid in one
of the larger refactorings that I'm working on.
|
|
|
|
| |
Only `Date` and `Time` are handled.
|
| |
|
|
|
|
|
|
|
| |
This adds a regression test for #14411, which was fixed by #15503.
Closes #14411
Closes #14595
|
|\
| |
| | |
Refactor quoting of binary data to not be based on the column type
|
| | |
|
|/
|
|
|
| |
The types know more about what is going on than the dirty module. Let's
ask them!
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Nearly completely implemented in terms of custom properties.
`_before_type_cast` now stores the raw serialized string consistently,
which removes the need to keep track of "state". The following is now
consistently true:
- `model.serialized == model.reload.serialized`
- A model can be dumped and loaded infinitely without changing
- A model can be saved and reloaded infinitely without changing
|
|
|
|
|
|
|
| |
This removes the case statement in `SchemaDumper` and gives every `Type`
the possibility to control the SchemaDumper default value output.
/cc @sgrif
|
| |
|
|
|
|
|
|
|
| |
Many of the methods defined in `AttributeMethods::Serialization` can be
refactored onto this type as well, but this is a reasonable small step.
Removes the `Type` class, and the need for `decorate_columns` to handle
serialized types.
|
|
`ActiveRecord::ConnectionAdapters::Type::Value` =>
`ActiveRecord::Type::Value`
|