Rails 5 belongs_to association behavior overridden
jmhooper opened this issue · 12 comments
In Rails 5 belongs to associations are required by default. For some reason, after adding delayed_job_active_record to my Gemfile the presence of associated records was no longer required.
Here's how this can be reproduced:
- Generate a new rails app with rails 5.0.0.rc1.
- Generate 2 models that share a relationship:
class MyModel < ApplicationRecord
belongs_to :my_related_model # This should imply a presence validation in Rails 5
end
class MyRelatedModel < ApplicationRecord
has_many :my_models
end- Check that the presence of a
MyRelatedModelis required for a validMyModel
m = MyModel.new
m.valid? #=> false
m.errors.full_messages #=> ["My related model must exist"]- Add
delayed_job_active_recordto the Gemfile and run through the installation instructions in thedelayed_jobREADME
gem "delayed_job_active_record"$ bundle install
$ rails generate delayed_job:active_record
$ rake db:migrate- Check that the presence of a
MyRelatedModelis required for a validMyModel
m = MyModel.new
m.valid? #=> true
m.errors.full_messages #=> []I can confirm that this is an issue in my Rails 5.0 (final release) app. I have failures in my test suite when adding DJ. I pulled the branch in #106, rebased against master, and all specs passed again. Can we get an ETA on when that PR could be merged and the gem released?
Hate to ping again, but any update on this? Would love to get this released so we can move to Rails 5. As mentioned, #106 fixes my issues.
As a temporary work-around, adding optional: false to the belongs_to statement seems to retain the validation behaviour Rails 5 introduces on this type of relation.
Wow, this is absurd. Just ran into this as well.
Any updates on status of this issue?
Unfortunately the problem is more complicated than the proposed solution. In the proposed solution, if something outside DJ doesn't touch ActiveRecord then DJ is never configured. Yes the solution does work for some situations, but not all situations.
@albus522 Is that something that you think is a likely issue? I spent a lot of time with this bug in particular across several gems when Rails 5 launched. Obviously a while ago, but in my recollection the solution in every instance was to use the ActiveSupport.on_load(:active_record) hook. It’s also the solution the Rails core team suggested, which in my mind gives the fix some confidence.
@lleger yes, it is how the Rails team wants you to do it, however, how DJ uses AR is more how your app uses AR and less like how a library augments AR. This puts DJ in a weird place because of how all the Rails app initialization works. There is also one more wrinkle in how DJ works in that we don't require Rails. You will notice our dependency is on AR not Rails. AR is perfectly usable outside of a Rails app context and there have been a number of changes over the years to make sure DJ doesn't require Rails to function.
All this to say, the problem is more complicated than it appears on the surface.
I see. Would it hurt to tie into the Rails stack with that fix only if Rails is loaded? Would fix the problem without depending on Rails being there, only playing nice with it if it is indeed present.
We will have to tie into the rails initialization process somehow when it is present, but we will have to do more than the current PR does to ensure that DJ is configured even if AR isn't touched by the time the initialization has finished. Most of the time in production, that won't be an issue, however, in development and other edge cases it will absolutely be an issue.