I have a rails engine which encapsulates a piece of my application's funtionality. I have a bunch of models in the engine, which have various belongs_to associations defined. As of rails 5 these associations are supposed to be required by default, unless optional: true is specified in the definition.
I’m still able to create instances of the models without any validation errors. I haven’t specified optional: true on any of the associations, nor is the config optionconfig.active_record.belongs_to_required_by_default set anywhere. Besides, it was removed in rails 6 anyway.
I can't think of any reason the model instances would not fail validation. I would expect any instances of any model with an undefined belongs_to association would be invalid and raise an error. Why would these records pass validation?
I found my problem, thanks to #MatthiasWinkelmann for the tip. It turns out my engine was not calling load_defaults at all. I needed to add the following to spec/dummy/config/application.rb:
module Dummy
class Application < Rails::Application
config.load_defaults Rails::VERSION::STRING.to_f
... etc ....
end
end
here is an article containing more explanation:
An upgraded Rails gem does not upgrade your Rails configuration
I probably would have done better to mention in my question that I'm in the process of upgrading my application from Rails 4.2 to 6.1. The change was introduced in Rails 5.
Related
I'm working on upgrading a Ruby 2.2.2 (Rails 4.1) app to Ruby 2.5.7 (Rails 5.2) and for a couple of models I'm getting some errors
From searching around, it sounds like there are some generic activerecord validation rules / messages? The messages are:
Status is invalid
User is invalid`
I am a novice at best with Ruby - so any suggestions on the best way to work through this error are appreciated!
In Rails 5, whenever a belongs_to association is defined, it is required to have the associated record present by default. That means, compared to Rails 4, each belongs_to :foo association basically adds internally a validate :foo, presence: true to the code too.
You have two choices:
Follow the new Ruby on Rails conventions and fix your tests by adding all required associated objects to the models.
Switch back to the old behavior for these kinds of associations by adding , optional: true to each belongs_to :foo line in your code.
There is actually the third option to switch off this behavior in the whole application, by adding a line like this to your application.rb
Rails.application.config.active_record.belongs_to_required_by_default = true
But that means your application will not follow Ruby on Rails conventions and defaults anymore and IMHO this ofter leads to problems with a later update.
Therefore my advice is: Fix your tests now and only make those associations optional that are really optional from the user's point of view – this might take a bit longer but causes certainly less trouble in the future.
I am upgrading old rails 2 app to rails 4. There are some code written in the model for creating like
create(activated: true, sita_code: MULTIPROPERTY.downcase,
access_list: MULTIPROPERTY.downcase)
I know we add permit parameters on controllers but I am getting this issue on model. How can I solve this
If you are working with Rails < 4.2, you might need to declare all the attributes under the corresponding model. So for about answer will be
attr_accessible :activated, :sita_code, :access_list
I have a gem that has two active record models Model A and Model B. Model B MUST have a reference to Model A if another field is true and CANNOT have a reference to Model A if that other field is false.
validates_presence_of :model_a_id, if: :external
validates_absence_of :model_a_id, unless: :external
Our gem is tested using combustion. When running the engine or gem through combustion everything works fine. We can create Model B in all instances. When our gem is consumed by our other application, you cannot create Model B if the external is false, as it gives you:
1 error prohibited this model_b from being saved:
Model A must exist
This previously worked prior to being on Rails 5. After investigating why this could be happening I landed on this configuration that is present in the initializers. This configuration exists in the application that consumes our gem, but not the gem itself.
Rails.application.config.active_record.belongs_to_required_by_default = false
If I put this configuration item in my gem and set it to false, nothing changes. When ran through combustion I can create Model B with external set to false. When ran through the application, I still cannot create Model B, with the same error as above.
When I put this configuration item in my gem and set it to true, I can no longer create Model B, with the same error as when I run the gem through the application. The same result happens with the application.
I've been stumped on what to do to resolve this issue and any help would be appreciated.
I believe I have figured out how to fix this. I'm unsure why the configuration in the initializers didn't work, but on the belongs_to :model_a I changed it to:
belongs_to :model_a, optional: true
To my knowledge, the new default in Rails 5 requires belongs_to associations to be present. I made a model with this association, but the problem is I don't get presence validation error when the associated field is empty. Instead I get a database Null Validation error since I set the _id column not to be null. (PG::NotNullViolation because I use Postgres)
Is this behaviour normal? I mean shouldn't I get the rails error only?
BTW, when I add presence validation for the field, it works as I expected.
According to the issue re weird behaviour of config belongs_to_required_by_default, it seems like one of your other gems intervenes in ActiveRecord::Base and causes the bug.
One of workarounds to the issue is to move the line
config.active_record.belongs_to_required_by_default = true
from initializers directly into application.rb.
This worked for me smoothly.
New Rails 5 applications come with a new initializer in
config/initializers/active_record_belongs_to_required_by_default.rb
If you upgraded a Rails 4 application or created your application with a beta version of Rails 5, then that file might be missing.
The configuration in that file enables the feature in question:
# Be sure to restart your server when you modify this file.
# Require `belongs_to` associations by default. This is a new Rails 5.0
# default, so it is introduced as a configuration option to ensure that apps
# made on earlier versions of Rails are not affected when upgrading.
Rails.application.config.active_record.belongs_to_required_by_default = true
Please check how belongs_to_required_by_default is configured in your application.
I faced with same problem.
You can move
config.active_record.belongs_to_required_by_default = false
to config/environments/needed_environment.rb or to config/application.rb
Helped for me!
I'm trying to generate some models but they are being generated without attributes.
I'm using a linux system and the rails version is:
rails --version
Rails 4.0.0
I've tried to generate the models using this commands:
rails g scaffold Bsdsd description:string test:string oaso:integer
and
rails g model Asdsd description:string test:string oaso:integer
The first results in this empty class model everything else ok:
class Bsdsd < ActiveRecord::Base
end
The second results in test files, migrations file(that contains the attributes) and this class model:
class Asdsd < ActiveRecord::Base
end
How can I correct this behavior?
Model attributes are inferred from database columns, so you don't need them specified in model classes.
In Rails 3.2 you had (if I remember correctly)
# attr_accessible :description, :test, :oaso
line generated. But protected attributes are deprecated in Rails 4.0 and replaced by strong parameters mechanism.
Nothing you're doing is wrong. But you're checking the wrong files. Look for CreateAsdsdsMigration (in the migrations directory) file and you'll see the auto-generated fields there
For those coming from Grails or Django, note that Rails creates the database FIRST-- not the other way around, where domainclass.groovy or models.py creates the database tables for you AFTER you define them. Look for yourapp/db/schema.rb and inside are all your classes and their field definitions.