| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|