aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/associations/has_one_association.rb
Commit message (Collapse)AuthorAgeFilesLines
* Refs #28025 nullify *_type column on polymorphic associations on :nu… ↵Laerti2019-01-151-1/+1
| | | | | | (#28078) This PR addresses the issue described in #28025. On `dependent: :nullify` strategy only the foreign key of the relation is nullified. However on polymorphic associations the `*_type` column is not nullified leaving the record with a NULL `*_id` but the `*_type` column is present.
* Initialization block is a part of `build_record`Ryuta Kamizono2018-06-041-1/+1
| | | | Should be done before `before_add` callbacks.
* Don't expose `SingularAssociation#replace` which is internal APIRyuta Kamizono2018-05-161-29/+27
| | | | | Originally `SingularAssociation#replace` abstract method is private, and doesn't intend to be called directly.
* Allow a belonging to object to be created from a new recordJolyon Pawlyn2018-05-011-0/+8
| | | | If a 'has one' object is created from a new record, an ActiveRecord::RecordNotSaved error is raised but this behavior was also applied to the reverse scenario.
* Fix dependence on has_one/belongs_to relationshipsFernando Gorodscy2018-03-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | When a class has a belongs_to or has_one relationship with dependent: :destroy option enabled, objects of this class should not be deleted if it's dependents cannot be deleted. Example: class Parent has_one :child, dependent: :destroy end class Child belongs_to :parent, inverse_of: :child before_destroy { throw :abort } end c = Child.create p = Parent.create(child: c) p.destroy p.destroyed? # expected: false; actual: true; Fixes #32022
* Fix broken doc for Active Record [ci skip]Yoshiyuki Hirano2017-08-251-1/+1
|
* Merge pull request #29855 from lugray/has_one_destroyed_by_associationRafael França2017-07-211-0/+2
|\ | | | | Match destroyed_by_association for has_one to has_many
| * Match destroyed_by_association for has_one to has_manyLisa Ugray2017-07-211-0/+2
| | | | | | | | | | | | | | When a has_many association is destroyed by `dependent: destroy`, destroyed_by_association is set to the reflection, and this can be checked in callbacks. This matches that behaviour for has_one associations.
* | Use frozen-string-literal in ActiveRecordKir Shatrov2017-07-191-0/+2
|/
* Revert "Merge pull request #29540 from kirs/rubocop-frozen-string"Matthew Draper2017-07-021-1/+0
| | | | | This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
* Enforce frozen string in RubocopKir Shatrov2017-07-011-0/+1
|
* Reduce string objects by using \ instead of + or << for concatenating stringsAkira Matsuda2017-01-121-1/+1
| | | | (I personally prefer writing one string in one line no matter how long it is, though)
* Remove deprecated i18n scopes in Active RecordRafael Mendonça França2016-12-291-8/+1
|
* Allow `autosave: true` to be used with inverse ofSean Griffin2016-11-011-1/+2
| | | | | | | | | | | | | | | | | With the changes in #25337, double save bugs are pretty much impossible, so we can just lift this restriction with pretty much no change. There were a handful of cases where we were relying on specific quirks in tests that had to be updated. The change to has_one associations was due to a particularly interesting test where an autosaved has_one association was replaced with a new child, where the child failed to save but the test wanted to check that the parent id persisted to `nil`. I think this is almost certainly the wrong behavior, and I may change that behavior later. But ultimately the root cause was because we never remove the parent in memory when nullifying the child. This makes #23197 no longer needed, but it is what we'll do to fix some issues on 5.0 Close #23197
* Deprecate the behavior of AR::Dirty inside of after_(create|update|save) ↵Sean Griffin2016-11-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | callbacks We pretty frequently get bug reports that "dirty is broken inside of after callbacks". Intuitively they are correct. You'd expect `Model.after_save { puts changed? }; model.save` to do the same thing as `model.save; puts model.changed?`, but it does not. However, changing this goes much farther than just making the behavior more intuitive. There are a _ton_ of places inside of AR that can be drastically simplified with this change. Specifically, autosave associations, timestamps, touch, counter cache, and just about anything else in AR that works with callbacks have code to try to avoid "double save" bugs which we will be able to flat out remove with this change. We introduce two new sets of methods, both with names that are meant to be more explicit than dirty. The first set maintains the old behavior, and their names are meant to center that they are about changes that occurred during the save that just happened. They are equivalent to `previous_changes` when called outside of after callbacks, or once the deprecation cycle moves. The second set is the new behavior. Their names imply that they are talking about changes from the database representation. The fact that this is what we really care about became clear when looking at `BelongsTo.touch_record` when tests were failing. I'm unsure that this set of methods should be in the public API. Outside of after callbacks, they are equivalent to the existing methods on dirty. Dirty itself is not deprecated, nor are the methods inside of it. They will only emit the warning when called inside of after callbacks. The scope of this breakage is pretty large, but the migration path is simple. Given how much this can improve our codebase, and considering that it makes our API more intuitive, I think it's worth doing.
* code gardening: removes redundant selfsXavier Noria2016-08-081-1/+1
| | | | | | | | | A few have been left for aesthetic reasons, but have made a pass and removed most of them. Note that if the method `foo` returns an array, `foo << 1` is a regular push, nothing to do with assignments, so no self required.
* applies remaining conventions across the projectXavier Noria2016-08-061-16/+16
|
* Merge branch 'master' of github.com:rails/docrailsVijay Dev2015-09-181-1/+1
|\
| * [ci skip] Fix module name of documentyui-knk2015-09-171-1/+1
| |
* | `restrict_with_error` message will now respect owner’s human name in any ↵Ronak Jangir2015-09-121-1/+1
|/ | | | locale [kuboon & Ronak Jangir]
* Only nullify persisted has_one target associationsAgis-2015-08-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Since after 87d1aba3c `dependent: :destroy` callbacks on has_one assocations run *after* destroy, it is possible that a nullification is attempted on an already destroyed target: class Car < ActiveRecord::Base has_one :engine, dependent: :nullify end class Engine < ActiveRecord::Base belongs_to :car, dependent: :destroy end > car = Car.create! > engine = Engine.create!(car: car) > engine.destroy! # => ActiveRecord::ActiveRecordError: cannot update a > destroyed record In the above case, `engine.destroy!` deletes `engine` and *then* triggers the deletion of `car`, which in turn triggers a nullification of `engine.car_id`. However, `engine` is already destroyed at that point. Fixes #21223.
* Deprecate and rename the keys for association restrict_dependent_destroyRoque Pinel2015-07-201-1/+8
| | | | | | | | | | | | | | | | | Previously `has_one` and `has_many` associations were using the `one` and `many` keys respectively. Both of these keys have special meaning in I18n (they are considered to be pluralizations) so by renaming them to `has_one` and `has_many` we make the messages more explicit and most importantly they don't clash with linguistical systems that need to validate translation keys (and their pluralizations). The `:'restrict_dependent_destroy.one'` key should be replaced with `:'restrict_dependent_destroy.has_one'`, and `:'restrict_dependent_destroy.many'` with `:'restrict_dependent_destroy.has_many'`. [Roque Pinel & Christopher Dell]
* Deprecate `false` as the way to halt AR callbacksclaudiob2015-01-021-1/+1
| | | | | | | | | | Before this commit, returning `false` in an ActiveRecord `before_` callback such as `before_create` would halt the callback chain. After this commit, the behavior is deprecated: will still work until the next release of Rails but will also display a deprecation warning. The preferred way to halt a callback chain is to explicitly `throw(:abort)`.
* Share foreign_key_present? implementation in _has_ associationsbrainopia2014-12-311-0/+1
|
* remove blank lines in the start of the ActiveRecord filesPonomarev Nikolay2014-07-291-1/+0
|
* Fixes problem with replacing has_one association record with itselfDenis Redozubov2013-11-111-2/+4
|
* Merge pull request #12135 from dylanahsmith/avoid_empty_transactionRafael Mendonça França2013-09-111-1/+3
|\ | | | | | | | | | | | | Avoid empty transaction from setting has_one association on new record. Conflicts: activerecord/CHANGELOG.md
| * Avoid empty transaction from setting has_one association on new record.Dylan Thacker-Smith2013-09-111-1/+2
|/
* Revert "Merge pull request #11416 from tigrish/master"Yves Senn2013-07-221-1/+1
| | | | | This reverts commit 9dc8aef084fc5ae7e3a396dd098d89da93d06fda, reversing changes made to 02e8dae6279ea25312293a3eca777faf35139c4c.
* Remove ambiguity with pluralizations and I18n keys used for association ↵Christopher Dell2013-07-131-1/+1
| | | | restrict_dependent_destroy errors
* Dropped deprecated option `:restrict` for `:dependent` in associationsNeeraj Singh2013-07-031-1/+1
|
* Fix #8856 Ensure has_one association=(associate) triggers save.Chris Thompson2013-04-301-3/+2
| | | | | | | | | | | | | | | | | | | | | | | activerecord/lib/active_record/associations.rb states: # [association=(associate)] # Assigns the associate object, extracts the primary key, sets it as the foreign key, # and saves the associate object. Since commit 42dd5d9f2976677a4bf22347f2dde1a8135dfbb4 to fix #7191, this is no longer the case if the associate has changed, but is the same object. For example: # Pirate has_one :ship pirate = Pirate.create!(catchphrase: "A Pirate") ship = pirate.build_ship(name: 'old name') ship.save! ship.name = 'new name' pirate.ship = ship That last line should trigger a save. Although we are not changing the association, the associate (ship) has changed.
* Adding a bang to method name of raise_on_type_mismatch.wangjohn2013-03-211-1/+1
|
* Do not create useless database transaction when building `has_one` association.Bogdan Gusiev2012-11-101-1/+9
|
* Fix grammarJo Liss2012-08-301-3/+3
|
* move dependency logic out of generated methodsJon Leighton2012-08-101-0/+18
|
* Fix #7191. Remove unnecessary transaction when assigning has_one associations.kennyj2012-08-081-13/+15
|
* removes usage of Object#in? from the code base (the method remains defined ↵Xavier Noria2012-08-061-9/+12
| | | | | | | | | | | | | | | | | | | by Active Support) Selecting which key extensions to include in active_support/rails made apparent the systematic usage of Object#in? in the code base. After some discussion in https://github.com/rails/rails/commit/5ea6b0df9a36d033f21b52049426257a4637028d we decided to remove it and use plain Ruby, which seems enough for this particular idiom. In this commit the refactor has been made case by case. Sometimes include? is the natural alternative, others a simple || is the way you actually spell the condition in your head, others a case statement seems more appropriate. I have chosen the one I liked the most in each case.
* load active_support/core_ext/object/inclusion in active_support/railsXavier Noria2012-08-021-1/+0
|
* Deprecate update_column in favor of update_columns.Rafael Mendonça França2012-07-241-1/+1
| | | | Closes #1190
* Remove update_attribute.Steve Klabnik2012-06-141-1/+1
| | | | | | | | | | | 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 removed in favor of update_column. See the thread on rails-core here: https://groups.google.com/forum/?fromgroups#!topic/rubyonrails-core/BWPUTK7WvYA
* Only call set_owner_attributes for has_one association if target exists.Dieter Komendera2011-07-041-1/+1
|
* When you add a record to a polymorphic has_one, you should be able to access ↵Jon Leighton2011-06-081-1/+1
| | | | the owner from the associated record
* Don't remove the target if it has already been destroyedAndrew White2011-05-111-1/+1
|
* Remove `#among?` from Active SupportPrem Sichanugrist2011-04-131-1/+1
| | | | | | After a long list of discussion about the performance problem from using varargs and the reason that we can't find a great pair for it, it would be best to remove support for it for now. It will come back if we can find a good pair for it. For now, Bon Voyage, `#among?`.
* Change Object#either? to Object#among? -- thanks to @jamesarosen for the ↵David Heinemeier Hansson2011-04-121-1/+1
| | | | suggestion!
* Using Object#in? and Object#either? in various placesPrem Sichanugrist2011-04-111-1/+3
| | | | There're a lot of places in Rails source code which make a lot of sense to switching to Object#in? or Object#either? instead of using [].include?.
* Move the code which builds a scope for through associations into a generic ↵Jon Leighton2011-03-101-6/+0
| | | | AssociationScope class which is capable of building a scope for any association.
* Use proper objects to do the work to build the associations (adding methods, ↵Jon Leighton2011-02-211-4/+15
| | | | callbacks etc) rather than calling a whole bunch of methods with rather long names.
* Delegate Association#options to the reflection, and replace ↵Jon Leighton2011-02-211-2/+2
| | | | 'reflection.options' with 'options'. Also add through_options and source_options methods for through associations.
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-28 21:22:05 +0000