aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/associations/has_one_association.rb
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* Singular associations no longer use a proxy, so no need to check for the ↵Jon Leighton2011-02-211-1/+1
| | | | proxy type on assignment.
* Associations - where possible, call attributes methods rather than directly ↵Jon Leighton2011-02-211-13/+13
| | | | accessing the instance variables
* Let's be less blasé about method visibility on association proxiesJon Leighton2011-01-301-1/+4
|
* find_target can also go into SingularAssociationJon Leighton2011-01-161-4/+0
|
* Abstract a bit more into SingularAssociationJon Leighton2011-01-161-2/+1
|
* Use self.target= rather than @target= as the former automatically sets loadedJon Leighton2011-01-161-2/+1
|
* Abstract common code from BelongsToAssociation and HasOneAssociation into ↵Jon Leighton2011-01-161-18/+5
| | | | SingularAssociation
* Support for create_association! for has_one associationsJon Leighton2011-01-111-1/+4
|
* When assigning a has_one, if anything fails, the assignment should be rolled ↵Jon Leighton2011-01-111-19/+23
| | | | back entirely
* When assigning a has_one, if the new record fails to save, raise an errorJon Leighton2011-01-111-3/+3
|
* When assigning a has_one, if the existing record fails to be removed from ↵Jon Leighton2011-01-111-5/+11
| | | | the association, raise an error
* has_one should always remove the old record (properly), even if not saving ↵Jon Leighton2011-01-111-1/+1
| | | | the new record, so we don't get the database into a pickle
* Refactor HasOneAssociation#replaceJon Leighton2011-01-071-26/+22
|
* Don't not remove double negativesJon Leighton2011-01-071-4/+4
|
* Clean up create, create! and build in HasOneAssociationJon Leighton2011-01-071-14/+8
|
* merge_with_conditions is not necessary because the conditions will already ↵Jon Leighton2011-01-071-9/+0
| | | | be in the scope_for_create hash in the scope
* Not really worth having the HasAssociation module for just a single methodJon Leighton2011-01-071-2/+0
|
* Construct an actual ActiveRecord::Relation object for the association scope, ↵Jon Leighton2011-01-071-11/+3
| | | | rather than a hash which is passed to apply_finder_options. This allows more flexibility in how the scope is created, for example because scope.where(a, b) and scope.where(a).where(b) mean different things.
* Remove undocumented feature from has_one where you could pass false as the ↵Jon Leighton2011-01-031-20/+8
| | | | | | | | | | | | second parameter to build_assoc or create_assoc, and the existing associated object would be untouched (the foreign key would not be nullified, and it would not be deleted). If you want behaviour similar to this you can do the following things: * Use :dependent => :nullify (or don't specify :dependent) if you want to prevent the existing associated object from being deleted * Use has_many if you actually want multiple associated objects * Explicitly set the foreign key if, for some reason, you really need to have multiple objects associated with the same has_one. E.g. previous = obj.assoc obj.create_assoc previous.update_attributes(:obj_id => obj.id)
* Create the association scope directly rather than going through with_scopeJon Leighton2011-01-031-2/+2
|
* Use the association directly in other places tooJon Leighton2011-01-031-11/+9
|
* Allow assignment on has_one :through where the owner is a new record [#5137 ↵Jon Leighton2011-01-031-3/+1
| | | | | | | | | | state:resolved] This required changing the code to keep the association proxy for a belongs_to around, despite its target being nil. Which in turn required various changes to the way that stale target checking is handled, in order to support various edge cases (loaded target is nil then foreign key added, foreign key is changed and then changed back, etc). A side effect is that the code is nicer and more succinct. Note that I am removing test_no_unexpected_aliasing since that is basically checking that the proxy for a belongs_to *does* change, which is the exact opposite of the intention of this commit. Also adding various tests for various edge cases and related things. Phew, long commit message!
* Rename AssociationReflection#primary_key_name to foreign_key, since the ↵Jon Leighton2010-12-311-3/+3
| | | | options key which it relates to is :foreign_key
* And owner_quoted_id can go tooJon Leighton2010-12-311-9/+0
|
* Refactor we_can_set_the_inverse_on_this? to use a less bizarre name amongst ↵Jon Leighton2010-12-261-8/+3
| | | | other things
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-07 09:33:36 +0000