| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\ \
| | |
| | | |
remove config.auto_explain_threshold_in_seconds
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We discussed that the auto explain feature is rarely used.
This PR removes only the automatic explain. You can still display
the explain output for any given relation using `ActiveRecord::Relation#explain`.
As a side-effect this should also fix the connection problem during
asset compilation (#9385). The auto explain initializer in the `ActiveRecord::Railtie`
forced a connection.
|
|/ /
| |
| |
| |
| |
| | |
We should only type cast when we need to use.
Related to 4b005fb371c2e7af80df7da63be94509b1db038c
|
| |
| |
| |
| | |
Closes #988.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
When a table or a column is renamed related indexes kept their name. This will lead to confusing names. This patch renames related indexes when a column or a table is renamed. Only indexes with names generated by rails will be renamed. Indexes with custom names will not be renamed.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some adapter (SQLite3) need to perform renaming operations to support
the rails DDL. These rename prefixes operate with prefixes. When an
index name already uses up the full space provieded by
`index_name_length` these internal operations will fail. This patch
introduces `allowed_index_name_length` which respects the amount of
characters used for internal operations. It will always be <=
`index_name_length` and every adapter can define how many characters
need to be reserved.
|
|\ \
| | |
| | |
| | |
| | | |
wangjohn/adding_documentation_to_error_raising_in_query_methods
Tests to make sure empty arguments in WhereChain raise errors
|
| | |
| | |
| | |
| | |
| | | |
for query methods in a where_clause. Also, modified the CHANGELOG entry
because it had false information and added tests.
|
|/ /
| |
| |
| | |
with new transaction state. If AR object has a callback, the callback will be performed immediately (non-lazily) so the transaction still has to keep records with callbacks.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
arguments are meaningless.
|
| |
| |
| |
| | |
[ci skip]
|
| |
| |
| |
| | |
closes #8423.
|
| |
| |
| |
| | |
fixes #5802
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Allow store accessors to be overrided like other attribute methods,
e.g.:
class User < ActiveRecord::Base
store :settings, accessors: [ :color, :homepage ], coder: JSON
def color
super || 'red'
end
end
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Describe better the changes related to raising errors with empty
array/hash values in where clauses.
[ci skip]
|
| | |
|
| | |
|
|/ |
|
|
|
|
| |
[ci skip]
|
| |
|
|
|
|
|
|
| |
the strings true and false into boolean types, in order to match how
YAML would parse the same values from database.yml and prevent
unexpected type errors in the database adapters.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This caused a bug with the new associations implementation, because now
association conditions are represented as Arel nodes internally right up
to when the whole thing gets turned to SQL.
In Rails 3.2, association conditions get turned to raw SQL early on,
which prevents Relation#merge from interfering.
The current implementation was buggy when a default_scope existed on the
target model, since we would basically end up doing:
default_scope.merge(association_scope)
If default_scope contained a where(foo: 'a') and association_scope
contained a where(foo: 'b').where(foo: 'c') then the merger would see
that the same column is representated on both sides of the merge and
collapse the wheres to all but the last: where(foo: 'c')
Now, the RHS of the merge is left alone.
Fixes #8990
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, when `time_zone_aware_attributes` were enabled, after
changing a datetime or timestamp attribute and then changing it back
to the original value, `changed_attributes` still tracked the
attribute as changed. This caused `[attribute]_changed?` and
`changed?` methods to return true incorrectly.
Example:
in_time_zone 'Paris' do
order = Order.new
original_time = Time.local(2012, 10, 10)
order.shipped_at = original_time
order.save
order.changed? # => false
# changing value
order.shipped_at = Time.local(2013, 1, 1)
order.changed? # => true
# reverting to original value
order.shipped_at = original_time
order.changed? # => false, used to return true
end
|
|
|
|
| |
closes #6865
|
| |
|
| |
|
|
|
|
|
|
|
| |
Suggested by @dhh.
It doesn't affect the generated SQL, so seems reasonable to continue to
allow it as an association option.
|
| |
|
|
|
|
| |
This is for commit e80546cdec56a9c3fcaf6217cba08a02d789d2bc.
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Other minor changelog improvements [ci skip]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|\
| |
| | |
Rename update_attributes method to update
|
| | |
|
|/ |
|