Unbreak update_column/update_columns for the primary key attribute. Conflicts: activerecord/CHANGELOG.md activerecord/lib/active_record/persistence.rb activerecord/test/cases/persistence_test.rb
I had to create a new table because I needed an STI table, which does not have both a "type" and a "custom_type" the test fails with: 1) Error: test_alt_becomes_works_with_sti(InheritanceTest): NoMethodError: undefined method `type=' for #<Cabbage id: 1, name: "my cucumber", custom_type: "Cucumber"> /Users/username/Projects/rails/activemodel/lib/active_model/attribute_methods.rb:432:in `method_missing' /Users/username/Projects/rails/activerecord/lib/active_record/attribute_methods.rbin `method_missing' /Users/username/Projects/rails/activerecord/lib/active_record/persistence.rb:165:in `becomes' test/cases/inheritance_test.rb:134:in `test_becomes_works_with_sti' test/cases/inheritance_test.rb:140:in `test_alt_becomes_works_with_sti' Conflicts: activerecord/test/cases/inheritance_test.rb
We have decided not to drop this important method in 4.0 and give it a longer deprecation cycle. On the other hand we do not expect to have update_column around for a long time, it is going to be replaced in favor of update_columns.
instead of update_column" This reverts commit 9fa06c3. This reverts commit 17a64de. This reverts commit def9c85, reversing changes made to 6b7d26c. Reason: This was supposed to be released with 3.2.7 before the suggestion to use update_column. Since it was not release now is not good to suggest to use another method because it will confusing the people.
update_column is deprecated in Rails 4.0 so it makes no sense to recommend adopting it only to require changing to update_columns in the very next release.
Historically, update_attribute and update_attributes are similar, but with one big difference: update_attribute does not run validations. These two methods are really easy to confuse given their similar names. Therefore, update_attribute is being deprecated in favor of update_column, and will be removed in Rails 4. See the discussion on rails-core here: https://groups.google.com/d/topic/rubyonrails-core/BWPUTK7WvYA/discussion
… object. This commit contains a simple failing test that demonstrates the behaviour we expect, and a fix. When using `becomes` to transform the type of an object, it should retain any error information that was present on the original instance.
Previously we would just silently write the attribute. This can lead to subtle bugs (for example, see the change in AutosaveAssociation where a through association would wrongly gain an attribute. Also, ensuring that we never gain any new attributes after initialization will allow me to reduce our dependence on method_missing.
…itor for generating SQL. This improves the code architecture generally, and solves some problems with marshalling. Adapter authors please take note: you now need to define an Adapter.visitor_for method, but it degrades gracefully with a deprecation warning for now.
… Fixes issue #402.
Conflicts: actionmailer/lib/action_mailer/base.rb activesupport/lib/active_support/core_ext/kernel/requires.rb
…d security guide
This reverts commit 45c233e. Signed-off-by: Santiago Pastorino <firstname.lastname@example.org>
Signed-off-by: Santiago Pastorino <email@example.com>
Conflicts: activerecord/examples/performance.rb activerecord/lib/active_record/association_preload.rb activerecord/lib/active_record/associations.rb activerecord/lib/active_record/associations/association_proxy.rb activerecord/lib/active_record/autosave_association.rb activerecord/lib/active_record/base.rb activerecord/lib/active_record/nested_attributes.rb activerecord/test/cases/relations_test.rb
…timistic locking [#5505 state:resolved] Signed-off-by: Santiago Pastorino and José Ignacio Costa <firstname.lastname@example.org>
Signed-off-by: Santiago Pastorino and José Ignacio Costa <email@example.com>