I’m using Rails 6.0.4.4 with Ruby 2.5.7. How do I construct a has-many-through association? I have these models with accompanying associations
class User < ActiveRecord::Base
has_many :roles_users
has_many :roles, through: :roles_users
class RolesUser < ActiveRecord::Base
belongs_to :user
belongs_to :role
end
class Role < ActiveRecord::Base
has_many :roles_users
But when I try and query the “has-many-through” association in the console, I get this argumenterzror …
> u = User.first
…
> u.roles
Traceback (most recent call last):
ArgumentError (wrong number of arguments (given 3, expected 2))
This worked fine when I was on Rails 4.2. What’s the proper way to set up a has-many-through in newer Rails?
Can you check your ransack gem version please ?
If it's 2.0 >, you have to update it
Related
Following Gedmo Tree manual I'd like to get tree of categories like the documentation shows:
$repository = $entityManager->getRepository(Category::class); $tree = $repository->childrenHierarchy();
however it throws an exception:
Invalid sort options specified: field - root, direction - asc
I faced the same issue and had to rollback the gedmo/doctrine-extensions version 3.7.
I'm trying to understand this relationship setup on this model, and why is this an issue on Rails 6.
Coming from Rails 3, this relationship is defined as:
belongs_to :entity foreign_key: 'user_id', foreign_type: 'ruby_type'
This worked fine, all the way up to Rails 5 (At least our crawl and traceroute did not bring this as an issue).
However, once we got to Rails 6, we found the following:
ArgumentError: Unknown key: :foreign_type. Valid keys are: :class_name, :anonymous_class, :primary_key, :foreign_key, :dependent, :validate, :inverse_of, :strict_loading, :autosave, :required, :touch, :polymorphic, :counter_cache, :optional, :default
Was this syntax changed for Rails 6?
foreign_type option can only be applied together with polymorphic - so make sure this is a polymorphic association you are after. If the association is not polymorphic I would get rid of foreign_type.
belongs_to :entity, foreign_key: 'user_id', foreign_type: 'ruby_type', polymorphic: true
In rails 5, I could make belongs_to association optional using this setting:
Rails.application.config.active_record.belongs_to_required_by_default = false
but this does not appear to work in Rails 6. Is there a way to do this in Rail 6?
Looking at the new framework defaults file for Rails 5, it had the following
# config/initializers/new_framework_defaults.rb
# Require `belongs_to` associations by default. Previous versions had false.
Rails.application.config.active_record.belongs_to_required_by_default = true
So it appears that the option has been removed completely for Rails 6. So you will need to do it on a case by case basis by adding optional: true. In my case, in most cases, I ended rewriting the code so that the association was required.
The option still works in Rails 6, but you need to make sure you set it after loading default config values, i.e.
config.load_defaults 6.0
The best place place would be towards the end of config/application.rb
...
# Don't check for the existence of belongs_to records
config.active_record.belongs_to_required_by_default = false
end
end
I am using the DataMapper gem with Sinatra and followed the tutorial here:
http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-working-with-datamapper/
I am connecting to the database and migrating as such:
DataMapper.setup :default, "sqlite://#{Dir.pwd}/ex2.db"
DataMapper.auto_migrate!
My data model:
class User
include DataMapper::Resource
property :id , Serial
property :username , String
property :email , String
end
I am executing using this command:
rackup config.ru
However, when I get to this line:
User.create username: "JoeSchmo", email: "joe#schmo.com"
I receive the error:
Rack::Lint::LintError: Status must be >=100 seen as integer
Any idea why this is happening?
Try deleting the SQLite DB - there seems to be a bug in data_mapper with changing the data structure and using old data. For me the bug went away after deleting the db and setting up a new one.
What version of ruby are you on because if you are on less than 1.9 you have to use the => hash constructor not : and move the colon to the beginning because it is a symbol.
User.create :username => "JoeSchmo", :email => "joe#schmo.com"
I had the same problem with Sinatra and datamapper. Creating my records with "new" keyword rather than "create" and then adding attributes one by one worked for me. Hope you find it useful.
I am currently having a strange issue with an application migrated from rails 2.3.8 to rails 3 (3.0.1, 3.0.2, 3.0.3).
At random moments associations behave strangely. In some cases, an associated object will return the Relation object, instead of the corresponding model. This seems to happen mostly on polymorphic associations. For example:
class A
belongs_to :b, :polymorphic => true
end
class B
has_many :a, :as => :source
end
When invoking "a.b" this will "sometimes" return the Relation object (causing a "undefined method ... for ActiveRecord::Relation" error to raise) and some other times it will return the correct B object.
When the relation object is returned, it may sometimes be "fixed" temporarily by restarting the server, but it will eventually show up again.
Another issue i get is that when "getting" associated objects, sometimes the required filters are not automatically applied (where element id = ...). this causes the query to return the first object in the table and not the correct associated object.
This is becoming a very frustrating issue, specially since i don't seem to find anyone else with this or similar issues.
All finder methods in the application have been migrated to the new rails form, but this strange behavior remains.
The current configuration being used is:
Ubuntu 10
nginx server
passenger (3.0.2)
rails (3.0.3)
ruby 1.9.2p0 (2010-08-18 revision 29036)
After digging a bit deeper into the Active Record code, my co-worker and I found that the belongs_to_association.rb and belongs_to_polymorphic_association.rb were still using the old finder methods in the "find_target" method.
We ran a couple tests by logging the resulting objects of this method from different queries and discovered the old finders were returning the ActiveRecord::Relation at random moments (loading the same object it would sometimes return the object and other times the Relation object).
We overrode the find_target method for these 2 classes in initializer files, changing the finders used there to the new rails3 format (klass.select(...).where(...), etc). This seems to have solved the issue.
The "has_many" association files are already using the new format, so these haven't caused any issues.
We applied these "fixes" to the rails 3.0.3 and hope that they will be resolved in future releases.
Here are our initializer files in case someone else bumps into this problem:
belongs_to_polymorphic_association.rb:
#initializers/belongs_to_polymorphic_association.rb
module ActiveRecord
# = Active Record Belongs To Polymorphic Association
module Associations
class BelongsToPolymorphicAssociation < AssociationProxy #:nodoc:
private
def find_target
return nil if association_class.nil?
target =
if #reflection.options[:conditions]
association_class.select(#reflection.options[:select]).where(conditions).where(:id => #owner[#reflection.primary_key_name]).includes(#reflection.options[:include]).first
else
association_class.select(#reflection.options[:select]).where(:id => #owner[#reflection.primary_key_name]).includes(#reflection.options[:include]).first
end
set_inverse_instance(target, #owner)
target
end
end
end
end
belongs_to_association.rb:
#initializers/belongs_to_association.rb
module ActiveRecord
# = Active Record Belongs To Associations
module Associations
class BelongsToAssociation < AssociationProxy #:nodoc:
private
def find_target
key_column = (#reflection.options[:primary_key]) ? #reflection.options[:primary_key].to_sym : :id
options = #reflection.options.dup
(options.keys - [:select, :include, :readonly]).each do |key|
options.delete key
end
options[:conditions] = conditions
the_target= #reflection.klass.select(options[:select]).where(key_column => #owner[#reflection.primary_key_name]).where(options[:conditions]).includes(options[:include]).readonly(options[:readonly]).order(options[:order]).first if #owner[#reflection.primary_key_name]
set_inverse_instance(the_target, #owner)
the_target
end
end
end
end
Hope this is useful for someome
Thanks for sharing this. The problem with associations gone. But I still had this issue even with straight "find" method.
#post = Post.find(params[:id)
#post.update_attributes...
will fail with ActiveRecord::Relation error. However
#post = Post.find_by_id(params[:id])
#post.update_attributes...
will work
Seems like strange lazy loading behaviour