It seems to me that you do not need to use polymorphic relationships here. You should be able to do this:
class User < ActiveRecord::Base
has_many :participations, class_name: 'Participant'
has_many :conversations, through: :participations
has_many :conversation_items, through: :conversations
end
class Participant < ActiveRecord::Base
belongs_to :user
belongs_to :conversation
end
class Conversation < ActiveRecord::Base
has_many :participants
has_many :conversation_items
end
class ConversationItem < ActiveRecord::Base
belongs_to :conversation
belongs_to :sender, class_name: 'User', foreign_key: 'sender_id'
end
To me, this makes more sense as a domain model, where a conversation has many participants. You can attach the sender to the conversation item, and every participant on the conversation, who is not the sender is implicitly the recipient. It does not make sense that a conversation would have a sender and a receiver, since a conversation is a two-way, or multi-way, dialogue.
The reason that polymorphic relationships do not work here is that polymorphic relationships are for situations where a table could refer to different types of items. For example, let's say that your ConversationItem had many attachments, and attachments could also be applied to posts. You would have something like:
class ConversationItem < ActiveRecord::Base
#...
has_many :attachments, as: :attachable
#...
end
class Post < ActiveRecord::Base
has_many :attachments, as: :attachable
end
class Attachment < ActiveRecord::Base
belongs_to :attachable, polymorphic: true
end
Where attachment would have the fields attachable_id and attachable_type. When you query attachments from conversation items, you would have a query like SELECT * FROM attachments where attachable_id = <id of the conversation item> and attachable_type = 'ConversationItem'. So polymorphic associations give you the ability to attach a model to many different types of other models.
In this case, you can see how it doesn't make sense to have polymorphic relationships, unless you were going to have many different types of models that send and receive conversation items because on your conversation_items table, you would have sender_type, sender_id, recipient_type, recipient_id.
Another issue that you have with your models is that you are trying to define the same relationship twice with different parameters. When you call has_many :foo, Rails is generating a bunch of different methods, like foos, foos=, and many more. If you call it again, you're just redefining those methods with the new parameters.
Followup
You don't necessarily need to have the Participant model. Having it gives you the ability to have multiple users participate, and it lets you avoid creating multiple relationships to same model. You can achieve the same thing with a has_and_belongs_to_many relationships, but you lose, should the need ever arise, the ability to attach extra attributes to the join table.
Say, for example, you wanted to allow people to exit a conversation without removing that they were once a participant, with a join model, you can add a boolean field call active, setting to false when someone exits. With HABTM, you couldn't do that. Having a participant leave would require that the pair be completely deleted from the join table. I usually prefer join models, like the Participation model here, since you never know how your schema may evolve.
That said, here is an example of the HABTM:
class User < ActiveRecord::Base
has_and_belongs_to_many :conversations
end
class Conversation < ActiveRecord::Base
has_and_belongs_to_many :users
end
Here you do not have a join model, but you will need to create a join table for this to work. An example of a migration for that would be:
create_table :conversations_users, :id => false do |t|
t.integer :conversation_id
t.integer :user_id
end
add_index :conversations_users, [:conversation_id, :user_id], unique: true
Where the name of the constituents of the join table are placed in alphabetical order, i.e. conversations_users, not users_conversations.
Further followup
If you use the Participant table, the foreign keys would be on participants and conversation_items.
participants
user_id
conversation_id
conversation_items
conversation_id
sender_id
