{"id":1645,"date":"2013-06-26T10:59:39","date_gmt":"2013-06-26T14:59:39","guid":{"rendered":"http:\/\/blogs.law.harvard.edu\/lianaleahy\/?p=1645"},"modified":"2013-06-26T10:59:39","modified_gmt":"2013-06-26T14:59:39","slug":"autosaveassociation","status":"publish","type":"post","link":"https:\/\/archive.blogs.harvard.edu\/lianaleahy\/2013\/06\/26\/autosaveassociation\/","title":{"rendered":"AutosaveAssociation"},"content":{"rendered":"

Recently, I wanted to utilize the AutosaveAssociation<\/a> module which (wrapped in a transaction) autosaves a model record when the parent is saved. I’ll use the example from the api docs:<\/p>\n

\r\npost = Post.new(title: 'ruby rocks')\r\npost.comments.build(body: 'hello world')\r\npost.save # => saves both post and comment\r\n<\/pre>\n
But because I had a validation on comments that requires presence of post, it was attempting to validate comments before post was created.  So instead of saving all my models in one swoop, it threw a validation error.<\/p>\n
Wut?  This should just work!  I fussed with it for hours and the only workaround appeared to be to call save<\/em> with validation: false<\/em>.<\/p>\n
Ew. Anyone else feel queasy?<\/p>\n
Turns out the missing piece was to add inverse_of<\/strong> on my model associations.  Here’s an awesome explanation from my coworker @mdaubs83<\/a>:<\/p>\n
The :inverse_of option is needed here to inform AR about the inverse association so that the Comment instance returned from build() can reference the original Post instance. This in turn allows the Comment instance to see the id of the Post instance after it’s saved and update it’s foreign key accordingly when AutosaveAssociation calls save() on associated objects. There are other benefits to using :inverse_of, we should probably consider adding the option to all associations. Here’s evidence of the issue and how adding inverse_of solves it:<\/p>\n
\r\npost.comments.build(user_id: user.id)\r\n\r\n# has_many :comments\r\npost.comments.first.post.object_id == post.object_id\r\n # => false\r\n\r\n# has_many :comments, :inverse_of => :post\r\npost.comments.first.post.object_id == post.object_id\r\n # => true\r\n<\/pre>\n
See also “Bi-directional associations” in Rails API Docs<\/a><\/p><\/blockquote>\n
Thanks, Matt!  Sadly, inverse_of<\/strong> is never mentioned in the AutosaveAssociation<\/a> docs.  But I noticed this line in the ActiveRecord Association<\/a> docs.<\/p>\n
If you are using a belongs_to on the join model, it is a good idea to set the :inverse_of option on the belongs_to, which will mean that the following example works correctly (where tags is a has_many :through association):<\/p>\n
\r\n@post = Post.first\r\n@tag = @post.tags.build :name => \"ruby\"\r\n@tag.save\r\n<\/pre>\n
The last line ought to save the through record (a Taggable). This will only work if the :inverse_of is set:<\/p>\n
\r\nclass Taggable ActiveRecord::Base\r\n  belongs_to :post\r\n  belongs_to :tag, :inverse_of => :taggings\r\nend\r\n<\/pre>\n<\/blockquote>\n
Err.  Okay.  Would have been useful to see that little tidbit included in the AutosaveAssociation<\/a> docs as well!<\/p>\n
But good news!  Matt also tells me that Rails 4.1 is poised to support automatic inverse_of<\/strong> detection.  So once we all upgrade we get inverse_of<\/strong> goodness for free.  W00t!<\/p>\n
\r\nCommit d6b03a3 to rails\/rails by wangjohn\r\nhttps:\/\/github.com\/rails\/rails\/commit\/d6b03a376787ec9c9e934e5688a38c576f2e39b7<\/a>\r\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
Recently, I wanted to utilize the AutosaveAssociation module which (wrapped in a transaction) autosaves a model record when the parent is saved. I’ll use the example from the api docs: post = Post.new(title: ‘ruby rocks’) post.comments.build(body: ‘hello world’) post.save # => saves both post and comment But because I had a validation on comments that […]<\/p>\n","protected":false},"author":1911,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[2850,2403],"tags":[],"class_list":["post-1645","post","type-post","status-publish","format-standard","hentry","category-professional","category-ruby-on-rails"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/archive.blogs.harvard.edu\/lianaleahy\/wp-json\/wp\/v2\/posts\/1645","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/archive.blogs.harvard.edu\/lianaleahy\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/archive.blogs.harvard.edu\/lianaleahy\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/lianaleahy\/wp-json\/wp\/v2\/users\/1911"}],"replies":[{"embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/lianaleahy\/wp-json\/wp\/v2\/comments?post=1645"}],"version-history":[{"count":43,"href":"https:\/\/archive.blogs.harvard.edu\/lianaleahy\/wp-json\/wp\/v2\/posts\/1645\/revisions"}],"predecessor-version":[{"id":1688,"href":"https:\/\/archive.blogs.harvard.edu\/lianaleahy\/wp-json\/wp\/v2\/posts\/1645\/revisions\/1688"}],"wp:attachment":[{"href":"https:\/\/archive.blogs.harvard.edu\/lianaleahy\/wp-json\/wp\/v2\/media?parent=1645"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/lianaleahy\/wp-json\/wp\/v2\/categories?post=1645"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/lianaleahy\/wp-json\/wp\/v2\/tags?post=1645"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}