| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were never clearing the `PG::Result` object used to query the types
when the connection is first established. This would lead to a
potentially large amount of memory being retained for the life of the
connection.
Investigating this issue also revealed several low hanging fruit on the
performance of these methods, and the number of allocations has been
reduced by ~90%.
Fixes #19578
|
|
|
|
|
|
| |
This is obviously all very internal, but sometimes you have to look at
it... and when you do, it'll save a lot of confusion if it doesn't lie
about its identity.
|
|
|
|
|
|
|
| |
The subtype will (quite reasonably) ignore the possibility that it has
`changed_in_place?` by becoming nil.
Fixes #19467
|
|
|
|
|
|
| |
* Fix a few typos
* Wrap some lines around 80 chars
* Rephrase some statements
|
|
|
|
| |
It is also necessary to format a time column like a datetime column.
|
|
|
|
|
|
|
|
|
| |
This helper no longer makes sense as a separate method. Instead I'll
just have `deserialize` call `cast` by default. This led to a random
infinite loop in the `JSON` pg type, when it called `super` from
`deserialize`. Not really a great way to fix that other than not calling
super, or continuing to have the separate method, which makes the public
API differ from what we say it is.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
We do this in the adapter classes specifically, so the types aren't
registered if we don't use that adapter. Constants under the PostgreSQL
namespace for example are never loaded if we're using mysql.
|
|
|
|
|
|
|
|
| |
As per previous discussions, we want to give users the ability to
reference their own types with symbols, instead of having to pass the
object manually. This adds the class that will be used to do so.
ActiveRecord::Type.register(:money, MyMoneyType)
|
|
|
|
|
|
|
|
|
| |
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.
|