| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
The latest version of the PG gem can actually convert the primitives for
us in C code, which gives a pretty substantial speed up. A few cases
were only there to add the `infinity` method, which I just put on the
range type (which is the only place it was used). Floats also needed to
parse `Infinity` and `NaN`, but it felt reasonable enough to put that on
the generic form.
|
|
|
|
|
|
|
|
|
|
| |
The various databases don't actually need significantly different
handling for this behavior, and they can achieve it without knowing
about the type of the object.
The old implementation was returning a string, which will cause problems
such as breaking TZ aware attributes, and making it impossible for the
adapters to supply their logic for time objects.
|
|
|
|
|
| |
If timestamp column have the precision, it need to format according to
the precision of timestamp column.
|
|
|
|
|
| |
This predicate is only used in `query_attribute`, and is relatively easy
to remove without adding a bunch of is a checks.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This predicate was only to figure out if it's safe to do case
insensitive comparison, which is only a problem on PG. Turns out, PG can
just tell us whether we are able to do it or not. If the query turns out
to be a problem, let's just replace that method with checking the SQL
type for `text` or `character`. I'd rather not burden the type objects
with adapter specific knowledge.
The *real* solution, is to deprecate this behavior entirely. The only
reason we need it is because the `:case_sensitive` option for
`validates_uniqueness_of` is documented as "this option is ignored for
non-strings". It makes no sense for us to do that. If the type can't be
compared in a case insensitive way, the user shouldn't tell us to do
case insensitive comparison.
|
|
|
|
|
|
|
| |
The type code is actually quite accessible, and I'm planning to
encourage people to look at the files in the `type` folder to learn more
about how it works. This will help reduce the noise from code that is
less about type casting, and more about random AR nonsense.
|
|
|
|
|
|
|
| |
It only existed to make sure the subclasses of `Delegator` were YAML
serializable. As of Ruby 2.2, these are YAML dumpable by default, as it
includes
https://github.com/tenderlove/psych/commit/2a4d9568f7d5d19c00231cf48eb855cc45ec3394
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to remove `Type::Value#klass`, as it was only used for
multi-parameter assignment to reach into the types internals. The
relevant type objects now accept a hash in addition to their previous
accepted arguments to `type_cast_from_user`. This required minor
modifications to the tests, since previously they were relying on the
fact that mulit-parameter assignement was reaching into the internals of
time zone aware attributes. In reaility, changing those properties at
runtime wouldn't change the accessor methods for all other forms of
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
|
|\
| |
| | |
Tiny: DRY default limit in ActiveRecord::Type::Integer
|
| | |
|
|/
|
|
|
|
|
| |
Says it's only used for the schema, but they are in fact used for
other things. Integer verifies against the limit during casting,
and Decimal uses precision during casting. It may be true that
scale is only used for the schema.
|
|
|
|
|
|
| |
The types that are affected by `time_zone_aware_attributes` (which is on
by default) have been made configurable, in case this is a breaking
change for existing applications.
|
| |
|
|
|
|
|
|
|
|
| |
Before this change we had a small set of "truthy", and all others
are "falsy".
Now, we have a small set of "falsy" values and all others are
"truthy" matching Ruby's semantics.
|
| |
|
|
|
|
|
|
|
|
| |
I think we should deprecate this behavior and just error if you tell us
to do a case insensitive comparison for types which are not case
sensitive. Partially reverts 35592307
Fixes #18195
|
|
|
|
|
|
|
| |
We were ignoring the `default_value?` escape clause in the serialized
type, which caused the default value to always be treated as changed.
Fixes #18169
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This bug occurs when an attribute of an ActiveRecord model is an
ActiveRecord::Type::Integer type or a ActiveRecord::Type::Decimal type (or any
other type that includes the ActiveRecord::Type::Numeric module. When the value
of the attribute is negative and is set to the same negative value, it is marked
as changed.
Take the following example of a Person model with the integer attribute age:
class Person < ActiveRecord::Base
# age :integer(4)
end
The following will produce the error:
person = Person.new(age: -1)
person.age = -1
person.changes
=> { "age" => [-1, -1] }
person.age_changed?
=> true
The problematic line is here:
module ActiveRecord
module Type
module Numeric
...
def non_numeric_string?(value)
# 'wibble'.to_i will give zero, we want to make sure
# that we aren't marking int zero to string zero as
# changed.
value.to_s !~ /\A\d+\.?\d*\z/
end
end
end
end
The regex match doesn't accept numbers with a leading '-'.
|
|
|
|
| |
Fixes #18122
|
| |
|
| |
|
|
|
|
|
| |
Thanks to @thedarkone for pointing out that an instance of this object
is used in a shared context.
|
| |
|
|
|
|
|
|
|
| |
It doesn't make sense for the subclass to implement this method, and not
have it on the parent. We can also DRY up the implementation of
`#lookup` to be defined in terms of fetch, which will give us a single
point of entry
|
|
|
|
| |
This reverts commit da99a2a2982d35f670ad9647463e09bfe9032b70.
|
|
|
|
|
|
|
|
| |
We don't have the check the range when the value is coming from the DB,
so override type_cast_from_database to short-circuit the extra work.
The difference is huge but the absolute gain is quite small. That being
said this is a hotspot and it showed up on the radar when benchmarking
discourse.
|
|
|
|
|
|
| |
This reverts commit 6f7910a and 52c70d4.
Query params are type cased through the same method, so this approach doesn't work.
|
|
|
|
| |
See comment on 6f7910a
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't have the check the range when the value is coming from the DB, so
override type_cast_from_database to short-circuit the extra work.
type_cast_from_database (small) 3437507.5 (±29.2%) i/s - 14223135 in 4.996973s
type_cast_from_database (large) 3158588.7 (±28.3%) i/s - 13265628 in 4.992121s
type_cast (small) 481984.8 (±14.2%) i/s - 2352012 in 5.005694s
type_cast (large) 477331.8 (±14.2%) i/s - 2332824 in 5.012365s
Comparison:
type_cast_from_database (small): 3437507.5 i/s
type_cast_from_database (large): 3158588.7 i/s - 1.09x slower
type_cast (small): 481984.8 i/s - 7.13x slower
type_cast (large): 477331.8 i/s - 7.20x slower
The difference is huge but the absolute gain is quite small. That being said
this is a hotspot and it showed up on the radar when benchmarking discourse.
|
| |
|
|
|
|
| |
There is a significant performance difference between the two. Closes
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|