| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
It appears this property was added, but never actually used. It would be
broken if it were, as it only type casts one way.
|
| |
|
|
|
| |
Adds the ability to save custom types, which type cast to non-primitive
ruby objects.
|
| |
|
|
|
|
|
|
| |
It appears to have been used at some point in the past, but is no longer
used in any meaningful way. Whether a column is considered primary is
a property of the model, not the schema/column. This also removes the
need for yet another layer of caching of the model's schema, and we can
leave that to the schema cache.
|
| |
|
|
|
| |
Columns and injected types no longer have any conditionals based on the
format of SQL type strings! Hooray!
|
| | |
|
| |
|
|
|
|
| |
Ideally types will be usable without having to specify a sql type
string, so we should keep the information related to parsing them on the
adapter or another object.
|
| | |
|
| |
|
|
|
|
|
| |
- `extract_precision`, `extract_limit`, and `extract_default` probably need to follow.
- would be good to remove the delegation `Column#extract_scale`.
/cc @sgrif
|
| | |
|
| | |
|
| |\
| |
| | |
Inline typecasting helpers from Column to the appropriate types
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
| |
All subclasses of column were now delegating `type_cast` to their
injected type object. We can remove the overriding methods, and
generalize it on the `Column` class itself. This also enabled us to
remove several column classes completely, as they no longer had any
meaningful behavior of their own.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The `:timestamp` type for columns is unused. All database adapters treat
them as the same database type. All code in `ActiveRecord` which changes
its behavior based on the column's type acts the same in both cases.
However, when the type is passed to code that checks for the `:datetime`
type, but not `:timestamp` (such as XML serialization), the result is
unexpected behavior.
Existing schema definitions will continue to work, and the `timestamp`
type is transparently aliased to `datetime`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The decision to wrap type registrations in a proc was made for two
reasons.
1. Some cases need to make an additional decision based on the type
(e.g. a `Decimal` with a 0 scale)
2. Aliased types are automatically updated if they type they point to is
updated later. If a user or another adapter decides to change the
object used for `decimal` columns, `numeric`, and `number` will
automatically point to the new type, without having to track what
types are aliased explicitly.
Everything else here should be pretty straightforward. PostgreSQL ranges
had to change slightly, since the `simplified_type` method is gone.
|
| |
|
|
|
|
| |
Part of #15134. In order to perform typecasting polymorphically, we need
to add another argument to the constructor. The order was chosen to
match the `oid_type` on `PostgreSQLColumn`.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
string with timezone. Closes #12278.
|
| |
|
|
|
|
|
|
| |
SQL doesn't have a string type, and interpreting 'string' as text is
contrary to at least SQLite3's behavior:
"Note that a declared type of 'STRING' has an affinity of NUMERIC, not TEXT."
http://www.sqlite.org/datatype3.html
|
| | |
|
| | |
|
| |
|
|
|
|
| |
as opposed to blank?
This is both faster and more correct, added tests to make sure this is not reverted again.
|
| |
|
|
|
|
|
|
|
|
| |
vipulnsward/change_from_blank_to_empty_on_string"
This reverts commit 9c4c05fc82e997b722dec4068c3aa27eaee69eb8, reversing
changes made to 4620bdcefd0c88905a005f191496df887877b8f3.
Reason: They're not completely interchangeable, since blank? will also
check for strings containing spaces.
|
| |
|
|
| |
calls
|
| |
|
|
|
|
| |
conversion of boolean types (true => 1 and false => 0). If the numeric value
being assigned is a BigDecimal, then ActiveRecord compares a BigDecimal to
true and false. This is known to be very slow in Ruby 1.9.3.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Also covers any non-castable case by returning nil, which
is in-line with the intention of the former implementation,
but covers the odd cases which respond to to_i but raise
an error when it's called, such as NaN, Infinity and -Infinity.
Fixes #8757
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit fixes a bug introduced in 96a13fc7 which breaks behaviour of
integer fields.
In 3.2.8, setting the value of an integer field to a non-integer (eg.
Array, Hash, etc.) would default to 1 (true) :
# 3.2.8
p = Post.new
p.category_id = [ 1, 2 ]
p.category_id # => 1
p.category_id = { 3 => 4 }
p.category_id # => 1
In 3.2.9 and above, this will raise a NoMethodError :
# 3.2.9
p = Post.new
p.category_id = [ 1, 2 ]
NoMethodError: undefined method `to_i' for [1, 2]:Array
Whilst at first blush this appear to be sensible, it combines in bad
ways with scoping.
For example, it is common to use scopes to control access to data :
@collection = Posts.where(:category_id => [ 1, 2 ])
@new_post = @collection.new
In 3.2.8, this would work as expected, creating a new Post object
(albeit with @new_post.category_id = 1). However, in 3.2.9 this will
cause the NoMethodError to be raised as above.
It is difficult to avoid triggering this error without descoping before
calling .new, breaking any apps running on 3.2.8 that rely on this
behaviour.
This patch deviates from 3.2.8 in that it does not retain the somewhat
spurious behaviour of setting the attribute to 1. Instead, it explicitly
sets these invalid values to nil :
p = Post.new
p.category_id = [ 1, 2 ]
p.category_id # => nil
This also fixes the situation where a scope using an array will
"pollute" any newly instantiated records.
@new_post = @collection.new
@new_post.category_id # => nil
Finally, 3.2.8 exhibited a behaviour where setting an object to an
integer field caused it to be coerced to "1". This has not been
retained, as it is spurious and surprising in the same way that setting
Arrays and Heshes was :
c = Category.find(6)
p = Post.new
# 3.2.8
p.category_id = c
p.category_id # => 1
# This patch
p.category_id = c
p.category_id # => nil
This commit includes explicit test cases that expose the original issue
with calling new on a scope that uses an Array. As this is a common
situation, an explicit test case is the best way to prevent regressions
in the future.
It also updates and separates existing tests to be explicit about the
situation that is being tested (eg. AR objects vs. other objects vs.
non-integers)
|
| | |
|
| |
|
|
|
|
|
| |
The Time.time_with_datetime_fallback, Time.utc_time and Time.local_time
methods were added to handle the limitations of Ruby's native Time
implementation. Those limitations no longer apply so we are deprecating
them in 4.0 and they will be removed in 4.1.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This can occur if the user is using :integer columns to store boolean
values. Now we are handling the boolean values but it still raises if
the value can't type cast to integer and is not a boolean. See #7509.
Fixes #8067.
Conflicts:
activerecord/CHANGELOG.md
|
| |
|
|
| |
It's sometimes hard to quickly find where deprecated call was performed, especially in case of migrating between Rails versions. So this is an attempt to improve the call stack part of the warning message by providing caller explicitly.
|
| |
|
|
|
|
|
|
|
| |
In non-strict mode it is '', but if someone is in strict mode then we
should honour the strict semantics.
Also, this removes the need for a completely horrible hack in dirty.rb.
Closes #7780
|
| |
|
|
|
|
|
|
|
|
|
| |
When inserting new records, only the fields which have been changed
from the defaults will actually be included in the INSERT statement.
The other fields will be populated by the database.
This is more efficient, and also means that it will be safe to
remove database columns without getting subsequent errors in running
app processes (so long as the code in those processes doesn't
contain any references to the removed column).
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This implements the support to encode/decode JSON
data to/from database and creating columns of type
JSON using a native type [1] supported by PostgreSQL
from version 9.2.
[1] http://www.postgresql.org/docs/9.2/static/datatype-json.html
|
| |
|
|
|
|
| |
The string_to_dummy_time method was blindly parsing the dummy time string
with Date._parse which returns a hash for the date part regardless
of whether the time part is an invalid time string.
|
| |
|
|
|
|
|
|
|
| |
ActiveRecord::ConnectionAdapters::Column#microseconds did an unnecessary
conversion to from Rational to float when calculating the integer number
of microseconds. Some terminating decimal numbers in base10 are
repeating decimal numbers in base2 (the format of float), and
occasionally this causes a rounding error.
Patch & explanation originally from Logan Bowers.
|
| | |
|
| |\
| |
| |
| |
| | |
danmcclain/add_inet_and_cidr_types_to_postgresql_adapter
Add support for macaddr, inet, and cidr types to PostgreSQL adapter
|
| | | |
|
| |/
|
|
| |
Issue #6045
|
| | |
|
