Another common Name for this model is the Supertype Model, where one has a base set of attributes that can be expanded via joining to another entity. In Oracle books, it is taught both as a logical model and physical implementation. The model without the relations would allow data to grow into invalid state and … Read more
Best practice to create has_one relation is to use the ActiveRecord callback before_create rather than after_create. Or use an even earlier callback and deal with the issues (if any) of the child not passing its own validation step. Because: with good coding, you have the opportunity for the child record’s validations to be shown to … Read more
TL;DR class User < ActiveRecord::Base def tasks Task.where(“owner_id = ? OR assigneed_id = ?”, self.id, self.id) end end Remove has_many :tasks in User class. Using has_many :tasks doesn’t make sense at all as we do not have any column named user_id in table tasks. What I did to solve the issue in my case is: … Read more
Here is the solution that works for me. FactoryGirl.define do factory :company do #company attributes end factory :user do companies {[FactoryGirl.create(:company)]} #user attributes end end if you will need specific company you can use factory this way company = FactoryGirl.create(:company, #{company attributes}) user = FactoryGirl.create(:user, :companies => [company]) Hope this will be helpful for somebody.
You’re misreading the docs slightly. some_firm.client.new is creating a new Client object from the clients collection, and so it can automatically set the firm_id to some_firm.id, whereas the docs are calling Client.new which has no knowledge of any Firm’s id at all, so it needs the firm_id passed to it. The only difference between some_firm.clients.new … Read more
You can do this all in the initial migration/column definition (at least currently in Rails 5): t.references :transferable_as, index: true, foreign_key: {to_table: :courses} t.references :same_as, index: true, foreign_key: {to_table: :courses}
The build method signature is different for has_one and has_many associations. class User < ActiveRecord::Base has_one :profile has_many :messages end The build syntax for has_many association: user.messages.build The build syntax for has_one association: user.build_profile # this will work user.profile.build # this will throw error Read the has_one association documentation for more details.
Depending on your query needs you can put everything in the user document: {name:”Joe” ,roles:[“Admin”,”User”,”Engineer”] } To get all the Engineers, use: db.things.find( { roles : “Engineer” } ); If you want to maintain the roles in separate documents then you can include the document’s _id in the roles array instead of the name: {name:”Joe” … Read more
The main differenece is that bidirectional relationship provides navigational access in both directions, so that you can access the other side without explicit queries. Also it allows you to apply cascading options to both directions. Note that navigational access is not always good, especially for “one-to-very-many” and “many-to-very-many” relationships. Imagine a Group that contains thousands … Read more
The difference is with the callback. The :delete_all is made directly in your application and deletes by SQL : DELETE * FROM users where compagny_id = XXXX With the :destroy, there is an instantiation of all of your children. So, if you can’t destroy it or if each has their own :dependent, its callbacks can … Read more