So I have a circular reference problem that I don't know how to solve. So the situation is the user has the ability to input a list of multiple films for actors into a text box. The text is held in a virtual attribute and parsed and given to the models in a model's save callback. Ideally I would not like to change the structure of the models because it makes english sense and seems very normal from a database standpoint.
Here's the structure:
require 'mongoid'
require 'mongo'
class Actor
include Mongoid::Document
field :name
attr_accessible :user_input_films
attr_accessor :user_input_films
before_save :assign_films
embeds_one :filmography
belongs_to :cast
def assign_films
if user_input_films == nil
return
end
user_input_films.split(" ").each do |film|
film = Film.first(conditions: { :name => film})
if film == nil
film = Film.new(:name => film)
film.build_cast
film.save!
end
self.filmography.add_film(film)
end
end
end
class Filmography
include Mongoid::Document
has_many :films
embedded_in :actor
def add_film(film)
films << film
film.cast.actors << self.actor
end
end
class Film
include Mongoid::Document
field :name
embeds_one :cast
belongs_to :filmography
end
class Cast
include Mongoid::Document
embedded_in :film
has_many :actors
end
Mongoid.configure do |config|
config.master = Mongo::Connection.new.db("mydb")
end
connection = Mongo::Connection.new
connection.drop_database("mydb")
database = connection.db("mydb")
actor = Actor.new
actor.build_filmography
actor.user_input_films = "BadFilm1 BadFilm2"
actor.save
puts "actor = #{actor.attributes}"
actor.filmography.films.each do |film|
puts "film = #{film.attributes}"
end
So the structure is: Actor owns Filmography which references many Films. And Film owns Cast which references many Actors. And the problem happens in the line:
film.cast.actors << self.actor
because the actor is then saved again through the << operator and the circular logic happens again
And as everyone guessed the error is:
/home/greg/.rvm/gems/ruby-1.9.2-p290#rails31/gems/mongoid2.2.1/lib/mongoid/fields.rb:307: stack level too deep (SystemStackError)
So how can I save my document without the circular reference stack overflow?
UPDATE:
One Thought, I think a dirty solution would be a way of adding a reference without saving the referenced object.
Thanks
Related
I want to write FactoryGirl class for creating company. The models are as follows:
module Company
class Contact
include Mongoid::Document
include ActiveModel::Validations
embedded_in :company, class_name: "::Company::Contact"
end
end
module Company
class Company
require 'autoinc'
embeds_many :contacts, class_name: "::Company::Contact"
end
end
FactoryGirl.define do
factory :company, :class => 'Company::Company' do
name { Faker::Company.name }
after(:create) do |company|
# company.contacts << create(:company_contact)
create_list(:company_contact, 1, company: company)
end
# contacts { [ build(:company_contact) ] }
end
end
The error received is
Failure/Error: create_list(:company_contact, 1, company: company)
Mongoid::Errors::InvalidPath:
message:
Having a root path assigned for Company::Contact is invalid.
summary:
Mongoid has two different path objects for determining the location of a document in the database, Root and Embedded. This error is raised when an embedded document somehow gets a root path assigned.
resolution:
Most likely your embedded model, Company::Contact is also referenced via a has_many from a root document in another collection. Double check the relation definitions and fix any instances where embedded documents are improperly referenced from other collections
How should I handle this? I cannot change the models.
You have the association class name wrong:
module Company
class Contact
include Mongoid::Document
include ActiveModel::Validations
embedded_in :company, class_name: 'Company::Company'
end
end
guys we are building a sort of address book, we have Users, Contacts and a parent Table called UserEntity. We want to relate them in a many-to-many association through a table called Relationship, this relations have to be in a self related in UserEntity table.
One User has many Contacts and one Contact has many Users.
Later on we need relate new models with Users so the Relationship model must be polymorphic. We already built this:
class UserEntity < ActiveRecord::Base
self.table_name = "users"
end
class User < UserEntity
has_many :relationships, as: :relatable
has_many :contacts, through: :relationships, source: :relatable, source_type "Contact"
end
class Contact < UserEntity
has_many :relationships, as: :relatable
has_many :users, through: :relationships, source: :relatable, source_type "User"
end
class Relationship < ActiveRecord::Base
belongs_to :user
belongs_to :relatable, polymorphic: true
end
but when we try to save the association user.contacts << contact the relatable_type field saves "UserEntity" value and not "Contact" or "User" value. We already tried to do this without any favorable results http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html#label-Polymorphic+Associations
How can we make that relatable_type value saves the model name ("Contact" || "User") and not the STI parent model name ("UserEntity")?
This is something known as STI base class, whereby Rails will save the Parent class, even though you've called the subclass. We have experience with it:
The above should have Node as Company...
I spent some time last year looking over this; there's a gem called store_sti_base_class:
Notice that addressable_type column is Person even though the actual class is Vendor.
Normally, this isn't a problem, however it can have negative performance characteristic in certain circumstances. The most obvious one is that a join with persons or an extra query is required to find out the actual type of addressable.
The way around it - at least from the perspective of the gem - is to extend ActiveRecord so that it will save the actual class of the model, not its parent.
The only code I have - which is out of date - is as follows:
#config/initializers/sti_base.rb
ActiveRecord::Base.store_base_sti_class = false
#lib/extensions/sti_base_class.rb
module Extensions
module STIBaseClass #-> http://stackoverflow.com/questions/2328984/rails-extending-activerecordbase
extend ActiveSupport::Concern
included do
class_attribute :store_base_sti_class
self.store_base_sti_class = true
end
end
# include the extension
ActiveRecord::Base.send(:include, STIBaseClass)
####
module AddPolymorphic
extend ActiveSupport::Concern
included do #-> http://stackoverflow.com/questions/28214874/overriding-methods-in-an-activesupportconcern-module-which-are-defined-by-a-cl
define_method :replace_keys do |record=nil|
super(record)
owner[reflection.foreign_type] = ActiveRecord::Base.store_base_sti_class ? record.class.base_class.name : record.class.name
Rails.logger.info record.class.base_class.name
end
end
end
ActiveRecord::Associations::BelongsToPolymorphicAssociation.send(:include, AddPolymorphic)
end
As I need to get this working, it might be worth bantering something around.
You must set UserEntity as abstract class:
class UserEntity < ActiveRecord::Base
self.table_name = "users"
self.abstract_class = true
end
Then value relatable_type can be User or Contact.
By default RoR save in relatable_type value of base_class method in your case:
class UserEntity < ActiveRecord::Base
end
class User < UserEntity
end
class Contact < UserEntity
end
irb(main):010:0> User.base_class.name
=> "UserEntity"
irb(main):011:0> Contact.base_class.name
=> "UserEntity"
When you make UserEntity as abstract class:
class UserEntity < ActiveRecord::Base
self.abstract_class = true
end
class User < UserEntity
end
class Contact < UserEntity
end
irb(main):010:0> User.base_class.name
=> "User"
irb(main):011:0> Contact.base_class.name
=> "Contact"
Here defined method which store class name (https://github.com/rails/rails/blob/master/activerecord/lib/active_record/associations/belongs_to_polymorphic_association.rb#L14):
def replace_keys(record)
super
owner[reflection.foreign_type] = record ? record.class.polymorphic_name : nil
end
def polymorphic_name
base_class.name
end
I basically want to create a concern which will be included in all the polymorphic models. This concern needs to have a dynamic setter method which which sets the value for the '_type' column.
module StiPolymorphable
extend ActiveSupport::Concern
included do
define_method "#{magic_method_to_get_type_column}=" do |type_field|
super(type_field.to_s.classify.constantize.base_class.to_s)
end
end
end
I basically want to access all the addresses of a Parent instance instead of a Person instance.
Example -
Suppose I have the following classes
class Person < ActiveRecord::Base
end
class Parent < Person end
class Teacher < Person end
class Address < ActiveRecord::Base
include StiPolymorphable
belongs_to :addressable, polymorphic: true
end
Right now if I try to access the addresses of a Parent it gives me zero records since the addressable_type field contains the value 'Person'.
Parent.first.addresses => #<ActiveRecord::Associations::CollectionProxy []>
Person.first.addresses => #<ActiveRecord::Associations::CollectionProxy [#<Address id: .....>]>
You might be interested on looking at Modularity gem so you could pass variables when you're including the Module. Haven't really tried it though. Hope it helps.
We do something like this:
module Shared::PolymorphicAnnotator
extend ActiveSupport::Concern
class_methods do
# #return [String]
# the polymorphic _id column
def annotator_id
reflections[annotator_reflection].foreign_key.to_s
end
# #return [String]
# the polymorphic _type column
def annotator_type
reflections[annotator_reflection].foreign_type
end
end
included do
# Concern implementation macro
def self.polymorphic_annotates(polymorphic_belongs, foreign_key = nil)
belongs_to polymorphic_belongs.to_sym, polymorphic: true, foreign_key: (foreign_key.nil? ? (polymorphic_belongs.to_s + '_id').to_s : polymorphic_belongs.to_s)
alias_attribute :annotated_object, polymorphic_belongs.to_sym
define_singleton_method(:annotator_reflection){polymorphic_belongs.to_s}
end
attr_accessor :annotated_global_entity
# #return [String]
# the global_id of the annotated object
def annotated_global_entity
annotated_object.to_global_id if annotated_object.present?
end
# #return [True]
# set the object when passed a global_id String
def annotated_global_entity=(entity)
o = GlobalID::Locator.locate entity
write_attribute(self.class.annotator_id, o.id)
write_attribute(self.class.annotator_type, o.class.base_class)
true
end
end
end
In your model:
class Foo
include Shared::PolymorphicAnnotator
polymorphic_annotates('belongs_to_name', 'foreign_key')
end
If one first build their models with a belong_to and has_many association and then realized they need to move to a embedded_in and embeds_many association, how would one do this without invalidating thousands of records? Need to migrate them somehow.
I am not so sure my solution is right or not. This is something you might try to accomplish it.
Suppose You have models - like this
#User Model
class User
include Mongoid::Document
has_many :books
end
#Book Model
class Book
include Mongoid::Document
field :title
belongs_to :user
end
At first step I will create another model that is similar to the Book model above but it's embedded instead of referenced.
#EmbedBook Model
class EmbedBook
include Mongoid::Document
field :title
embedded_in :user
end
#User Model (Update with EmbedBook Model)
class User
include Mongoid::Document
embeds_many :embed_books
has_many :books
end
Then create a Mongoid Migration with something like this for the above example
class ReferenceToEmbed < Mongoid::Migration
def up
User.all.each do |user|
user.books.each do |book|
embed_book = user.embed_books.new
embed_book.title = book.title
embed_book.save
book.destroy
end
end
end
def down
# I am not so sure How to reverse this migration so I am skipping it here
end
end
After running the migration. From here you can see that reference books are embedded, but the name for the embedded model is EmbedBook and model Book is still there
So the next step would be to make model book as embed instead.
class Book
include Mongoid::Document
embedded_in :user
field :title
end
class User
include Mongoid::Document
embeds_many :books
embeds_many :embed_books
end
So the next would be to migrate embedbook type to book type
class EmbedBookToBook < Mongoid::Migration
def up
User.all.each do |user|
user.embed_books.each do |embed_book|
book = user.books.new
book.title = embed_book.title
book.save
embed_book.destroy
end
end
def down
# I am skipping this portion. Since I am not so sure how to migrate back.
end
end
Now If you see Book is changed from referenced to embedded.
You can remove EmbedBook model to make the changing complete.
This is just the suggestion. Try this on your development before trying on production. Since, I think there might be something wrong in my suggestion.
10gen has a couple of articles on data modeling which could be useful:
Data Modeling Considerations for MongoDB Applications
Embedded One-to-Many Relationships
Referenced One-to-Many Relationships
MongoDB Data Modeling and Rails
Remember that there are two limitations in MongoDB when it comes to embedding:
the document size-limit is 16MB - this implies a max number of embedded documents, even if you just embed their object-id
if you ever want to search across all embedded documents from the top-level, then don't embed, but use referenced documents instead!
Try these steps:
In User model leave the has_many :books relation, and add the
embedded relation with a different name to not override the books
method.
class User
include Mongoid::Document
has_many :books
embeds_many :embedded_books, :class_name => "Book"
end
Now if you call the embedded_books method from a User instance
mongoid should return an empty array.
Without adding any embedded relation to Book model, write your own
migration script:
class Book
include Mongoid::Document
field :title, type: String
field :price, type: Integer
belongs_to :user
def self.migrate
attributes_to_migrate = ["title","price"] # Use strings not symbols,
# we keep only what we need.
# We skip :user_id field because
# is a field related to belongs_to association.
Book.all.each do |book|
attrs = book.attributes.slice(*attributes_to_migrate)
user = book.user // through belong_to association
user.embedded_book.create!(attrs)
end
end
end
Calling Book.migrate you should have all the Books copied inside each user who was
associated with belongs_to relation.
Now you can remove the has_many and belongs_to relations, and
finally switch to clean embedded solution.
class User
include Mongoid::Document
embeds_many :books
end
class Book
include Mongoid::Document
field :title, type: String
field :price, type: Integer
embedded_in :user
end
I have not tested this solution, but theoretically should work, let me know.
I have a much shorter concise answer:
Let's assume that you have the same models:
#User Model
class User
include Mongoid::Document
has_many :books
end
#Book Model
class Book
include Mongoid::Document
field :title
belongs_to :user
end
So change it to embeds:
#User Model
class User
include Mongoid::Document
embeds_many :books
end
#Book Model
class Book
include Mongoid::Document
field :title
embedded_in :user
end
And generate a mongoid migration like this:
class EmbedBooks < Mongoid::Migration
##attributes_to_migrate = [:title]
def self.up
Book.unscoped.where(:user_id.ne => nil).all.each do |book|
user = User.find book[:user_id]
if user
attrs = book.attributes.slice(*##attributes_to_migrate)
user.books.create! attrs
end
end
end
def self.down
User.unscoped.all.each do |user|
user.books.each do |book|
attrs = ##attributes_to_migrate.reduce({}) do |sym,attr|
sym[attr] = book[attr]
sym
end
attrs[:user] = user
Book.find_or_create_by(**attrs)
end
end
end
end
This works because when you query from class level, it is looking for the top level collection (which still exists even if you change your relations), and the book[:user_id] is a trick to access the document attribute instead of autogenerated methods which also exists as you have not done anything to delete them.
So there you have it, a simple migration from relational to embedded
I'm using Rails' accepts_nested_attributes_for method with great success, but how can I have it not create new records if a record already exists?
By way of example:
Say I've got three models, Team, Membership, and Player, and each team has_many players through memberships, and players can belong to many teams. The Team model might then accept nested attributes for players, but that means that each player submitted through the combined team+player(s) form will be created as a new player record.
How should I go about doing things if I want to only create a new player record this way if there isn't already a player with the same name? If there is a player with the same name, no new player records should be created, but instead the correct player should be found and associated with the new team record.
When you define a hook for autosave associations, the normal code path is skipped and your method is called instead. Thus, you can do this:
class Post < ActiveRecord::Base
belongs_to :author, :autosave => true
accepts_nested_attributes_for :author
# If you need to validate the associated record, you can add a method like this:
# validate_associated_record_for_author
def autosave_associated_records_for_author
# Find or create the author by name
if new_author = Author.find_by_name(author.name)
self.author = new_author
else
self.author.save!
end
end
end
This code is untested, but it should be pretty much what you need.
Don't think of it as adding players to teams, think of it as adding memberships to teams. The form doesn't work with the players directly. The Membership model can have a player_name virtual attribute. Behind the scenes this can either look up a player or create one.
class Membership < ActiveRecord::Base
def player_name
player && player.name
end
def player_name=(name)
self.player = Player.find_or_create_by_name(name) unless name.blank?
end
end
And then just add a player_name text field to any Membership form builder.
<%= f.text_field :player_name %>
This way it is not specific to accepts_nested_attributes_for and can be used in any membership form.
Note: With this technique the Player model is created before validation happens. If you don't want this effect then store the player in an instance variable and then save it in a before_save callback.
A before_validation hook is a good choice: it's a standard mechanism resulting in simpler code than overriding the more obscure autosave_associated_records_for_*.
class Quux < ActiveRecord::Base
has_and_belongs_to_many :foos
accepts_nested_attributes_for :foos, reject_if: ->(object){ object[:value].blank? }
before_validation :find_foos
def find_foos
self.foos = self.foos.map do |object|
Foo.where(value: object.value).first_or_initialize
end
end
end
When using :accepts_nested_attributes_for, submitting the id of an existing record will cause ActiveRecord to update the existing record instead of creating a new record. I'm not sure what your markup is like, but try something roughly like this:
<%= text_field_tag "team[player][name]", current_player.name %>
<%= hidden_field_tag "team[player][id]", current_player.id if current_player %>
The Player name will be updated if the id is supplied, but created otherwise.
The approach of defining autosave_associated_record_for_ method is very interesting. I'll certainly use that! However, consider this simpler solution as well.
Just to round things out in terms of the question (refers to find_or_create), the if block in Francois' answer could be rephrased as:
self.author = Author.find_or_create_by_name(author.name) unless author.name.blank?
self.author.save!
This works great if you have a has_one or belongs_to relationship. But fell short with a has_many or has_many through.
I have a tagging system that utilizes a has_many :through relationship. Neither of the solutions here got me where I needed to go so I came up with a solution that may help others. This has been tested on Rails 3.2.
Setup
Here are a basic version of my Models:
Location Object:
class Location < ActiveRecord::Base
has_many :city_taggables, :as => :city_taggable, :dependent => :destroy
has_many :city_tags, :through => :city_taggables
accepts_nested_attributes_for :city_tags, :reject_if => :all_blank, allow_destroy: true
end
Tag Objects
class CityTaggable < ActiveRecord::Base
belongs_to :city_tag
belongs_to :city_taggable, :polymorphic => true
end
class CityTag < ActiveRecord::Base
has_many :city_taggables, :dependent => :destroy
has_many :ads, :through => :city_taggables
end
Solution
I did indeed override the autosave_associated_recored_for method as follows:
class Location < ActiveRecord::Base
private
def autosave_associated_records_for_city_tags
tags =[]
#For Each Tag
city_tags.each do |tag|
#Destroy Tag if set to _destroy
if tag._destroy
#remove tag from object don't destroy the tag
self.city_tags.delete(tag)
next
end
#Check if the tag we are saving is new (no ID passed)
if tag.new_record?
#Find existing tag or use new tag if not found
tag = CityTag.find_by_label(tag.label) || CityTag.create(label: tag.label)
else
#If tag being saved has an ID then it exists we want to see if the label has changed
#We find the record and compare explicitly, this saves us when we are removing tags.
existing = CityTag.find_by_id(tag.id)
if existing
#Tag labels are different so we want to find or create a new tag (rather than updating the exiting tag label)
if tag.label != existing.label
self.city_tags.delete(tag)
tag = CityTag.find_by_label(tag.label) || CityTag.create(label: tag.label)
end
else
#Looks like we are removing the tag and need to delete it from this object
self.city_tags.delete(tag)
next
end
end
tags << tag
end
#Iterate through tags and add to my Location unless they are already associated.
tags.each do |tag|
unless tag.in? self.city_tags
self.city_tags << tag
end
end
end
The above implementation saves, deletes and changes tags the way I needed when using fields_for in a nested form. I'm open to feedback if there are ways to simplify. It is important to point out that I am explicitly changing tags when the label changes rather than updating the tag label.
Answer by #François Beausoleil is awesome and solved a big problem. Great to learn about the concept of autosave_associated_record_for.
However, I found one corner case in this implementation. In case of update of existing post's author(A1), if a new author name(A2) is passed, it will end up changing the original(A1) author's name.
p = Post.first
p.author #<Author id: 1, name: 'JK Rowling'>
# now edit is triggered, and new author(non existing) is passed(e.g: Cal Newport).
p.author #<Author id: 1, name: 'Cal Newport'>
Oringinal code:
class Post < ActiveRecord::Base
belongs_to :author, :autosave => true
accepts_nested_attributes_for :author
# If you need to validate the associated record, you can add a method like this:
# validate_associated_record_for_author
def autosave_associated_records_for_author
# Find or create the author by name
if new_author = Author.find_by_name(author.name)
self.author = new_author
else
self.author.save!
end
end
end
It is because, in case of edit, self.author for post will already be an author with id:1, it will go in else, block and will update that author instead of creating new one.
I changed the code(elsif condition) to mitigate this issue:
class Post < ActiveRecord::Base
belongs_to :author, :autosave => true
accepts_nested_attributes_for :author
# If you need to validate the associated record, you can add a method like this:
# validate_associated_record_for_author
def autosave_associated_records_for_author
# Find or create the author by name
if new_author = Author.find_by_name(author.name)
self.author = new_author
elsif author && author.persisted? && author.changed?
# New condition: if author is already allocated to post, but is changed, create a new author.
self.author = Author.new(name: author.name)
else
# else create a new author
self.author.save!
end
end
end
#dustin-m's answer was instrumental for me - I am doing something custom with a has_many :through relationship. I have a Topic which has one Trend, which has many children (recursive).
ActiveRecord does not like it when I configure this as a standard has_many :searches, through: trend, source: :children relationship. It retrieves topic.trend and topic.searches but won't do topic.searches.create(name: foo).
So I used the above to construct a custom autosave and am achieving the correct result with accepts_nested_attributes_for :searches, allow_destroy: true
def autosave_associated_records_for_searches
searches.each do | s |
if s._destroy
self.trend.children.delete(s)
elsif s.new_record?
self.trend.children << s
else
s.save
end
end
end