…issues [#6464] Fixes #6464 Synchronize the contents of the release method in ConnectionPool due to errors when running in high concurrency environments. Detected invalid hash contents due to unsynchronized modifications with concurrent users org/jruby/RubyHash.java:1356:in `keys' /usr/local/rvm/gems/jruby-1.6.7@new_import/gems/activerecord-3.2.3/lib/a ctive_record/connection_adapters/abstract/connection_pool.rb:294:in `release' /usr/local/rvm/gems/jruby-1.6.7@new_import/gems/activerecord-3.2.3/lib/a ctive_record/connection_adapters/abstract/connection_pool.rb:282:in `checkin'
Ruby 1.8 raises a TypeError when trying to modify a frozen Hash, while Ruby 1.9 raises a RuntimeError instead. Also, Ruby < 1.9.3 uses a lowercase 'hash' in the exception message while Ruby >= 1.9.3 uses an uppercase 'Hash' instead. This commit normalizes those issues in the test case.
This is a 3-2-stable backport for #6420 which was merged into master. Currently, when saving a frozen record, an exception would be thrown which causes a rollback. However, there is a bug in active record that "defrost" the record as a side effect: >> t = Topic.new => #<Topic id: nil, ...> >> t.freeze => #<Topic id: nil, ...> >> t.save RuntimeError: can't modify a frozen Hash >> t.frozen? => false >> t.save => true This patch fixes the bug by explictly restoring the frozen state on the attributes Hash after every rollback.
MySQL's adapter was changing value for case sensitive comparison. We don't need to do it for `nil`.
Closes (#5853) Uniqueness validator was not properly checking if there are any existing records, when value was `nil` and column was text type. `nil` was converted to string, which resulted in queries looking like: ```sql SELECT 1 FROM "posts" WHERE "posts"."title" = '' LIMIT 1 ``` instead of ```sql SELECT 1 FROM "posts" WHERE "posts"."title" IS NULL LIMIT 1 ```
The fix commited in e2a070c was returning the `new_target`, as a try to return whatever user replaced association with. The problem is, the resulting association target may be ordered differently. In such case we want to return the target that will be later used for that association.
Deprecate the use of AcitiveRecord::Fixtures::instantiate_fixtures(object, fixture_set_name, fixture_set, load_instances = true), use instead instantiate_fixtures(object, fixture_set, load_instances = true). To be changed in master branch.
String is Enumerable in 1.8.7, which means that passing a String to remove_column was generating deprecation warnings during tests.
… custom option Backports #5900 Conflicts: activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb activerecord/test/cases/adapters/mysql/mysql_adapter_test.rb
…coped (as described in #5667) Conflicts: activerecord/test/cases/associations/eager_test.rb
The #relation method gets called in four places and the return value was instantly cloned in three of them. The only place that did not clone was ActiveRecord::Scoping::Default::ClassMethods#unscoped. This introduced a bug described in #5667 and should really clone the relation, too. This means all four places would clone the relation, so it doesn't make a lot of sense caching it in the first place. The four places with calls to relations are: activerecord/lib/active_record/scoping/default.rb:110:in `block in build_default_scope'" activerecord/lib/active_record/scoping/default.rb:42:in `unscoped'" activerecord/lib/active_record/scoping/named.rb:38:in `scoped'" activerecord/lib/active_record/scoping/named.rb:52:in `scope_attributes'" Conflicts: activerecord/lib/active_record/core.rb