| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
for an unknown adapter
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
because of an ambiguous column name. This happened if the association
model had a default scope that referenced a third table, and the third
table also referenced the original table (with an identical
foreign_key).
Mysql requires that ambiguous columns are deambiguated by using the full
table.column syntax. Postgresql and Sqlite use a different syntax for
updates altogether (and don't tolerate table.name syntax), so the fix
requires always including the full table.column and discarding it later
for Sqlite and Postgresql.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
https://github.com/rails/rails/commit/4beb4dececcf10c642c74fbcb8548c833e921a86#commitcomment-2482869
|
| |
|
| |
|
|
|
|
|
|
| |
This reverts commit 4e05bfb8e254c3360a3ca4a6cb332995314338fe.
Reason: BlankTopic#blank? should not be removed to check that dynamic finder with a bang can find a model that responds to `blank?`
|
| |
|
|
|
|
| |
this would give us some more clues in case a test silently dies inside Thread
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Travis only has PostgreSQL 9.1.x but 9.2 is required for range datatypes.
|
|\
| |
| | |
Postgresql range support
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
The native JSON library bypasses the `to_json` overrides in
active_support/core_ext/object/to_json.rb by calling its native
implementation directly. However `ActiveRecord::Store` uses a
HWIA so `JSON.dump` will call our `to_json` instead with a
`State` object for options rather than a `Hash`. This generates
a warning when the `:encoding`, `:only` & `:except` keys are
accessed in `Hash#as_json` because the `State` object delegates
unknown keys to `instance_variable_get` in its `:[]` method.
Workaround this warning in the test by using a custom coder that
calls `ActiveSupport::JSON.encode` directly.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit e9d2ad395ec2ef929d74752f3d71c80674044fbe.
Closes #8460
Conflicts:
activerecord/lib/active_record/attribute_methods/time_zone_conversion.rb
activerecord/test/cases/dirty_test.rb
|
|
|
|
| |
Add a test case to ensure that fractional second updates are detected.
|
|
|
|
| |
[ci skip]
|
| |
|
| |
|
| |
|
|
|
|
| |
because some tests were not resetting them, and thus the tests were order dependent
|
| |
|
|
|
|
| |
new transaction state object upon initialization.
|
|
|
|
| |
Cleanup change_schema tests to remove extra sorts on columns.
|
|\
| |
| |
| |
| | |
seejee/regression_test_for_chained_preloaded_scopes
Added test case to prevent regression of chained, preloaded scopes.
|
| | |
|
|\ \
| | |
| | | |
Created state for a transaction and added tests.
|
| | | |
|
|/ / |
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Fix .update_all and .delete_all when using a condition on a joined table in a default_scope
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
in a default_scope.
`Model.joins(...).where(condition_on_joined_table).update_all` /
`delete_all` worked, but the same operation implemented with a
default_scope generated a SQL error because ActiveRecord ignored the
join but implemented the where condition anyways.
|
| | |
| | |
| | |
| | |
| | | |
This reverts commit 637a7d9d357a0f3f725b0548282ca8c5e7d4af4a, reversing
changes made to 5937bd02dee112646469848d7fe8a8bfcef5b4c1.
|
|\ \ \
| | | |
| | | | |
Replace deprecated find_by_* with find_by
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Suggested by @dhh.
It doesn't affect the generated SQL, so seems reasonable to continue to
allow it as an association option.
|
| | | |
| | | |
| | | |
| | | | |
Fixes #8795
|
|\ \ \ \
| |/ / /
|/| | | |
`CollectionAssociation#empty?` respects newly builded records
|
| | |/
| |/| |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If we set encoding latin1 for a PostgreSQL database, it calls
PostgreSQLAdapter::create_database with options that have,
among other things:
{ 'encoding' => 'latin1' }
Then, we use reverse_merge(:encoding => "utf8") to setup the default
encoding. In the end, the hash looks like:
{ :encoding => 'utf8', 'encoding' => 'latin1' }
The call to options.symbolize_keys calls to_sym on each_key of this
Hash. It usually means that the encoding passed overwrites the default
utf8, but it's not guaranteed. So, we shouldn't rely on it.
The same was happening in ActiveRecord::ConnectionHandling.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 1fc294f988e93ac59057a16b0e44b9cf93af9720, reversing
changes made to fb9ac47c286fbdfe05263d4d0346e50892090603.
Reason: these tests should run fine independent of database, since they
should only take into account the configuration options. The problem was
related to a change in the way "nil" is handled by the rescue clause, in
Ruby 2.0 it raises an exception asking for class or module, in 1.9 it
passes.
|