I was wondering what the community thought about an extension to the associations mechanism which allowed declarations like: class Game < AR::Base has_two :referees end I have run across this situation fairly frequently. An object has a defined number of subobjects of a particular type. In this situation I don''t necessarily want to use habtm or has_many :through. The join table just adds overhead to things like validation and ensuring that there are not more than 2 referees attached to the game, etc. This would be implemented db fields like referee_1_id, referee_2_id,etc.. This approach simplifies forms and object creation in the contexts where it is appropriate. If I had a list of referees, I could just do a collection_select for each referee, rather than having to worry about link up other records through a join table. Obviously this approach only applies to situations where there are a defined number of subobjects, but I find this to be a fairly common occurrence. Thoughts, comments? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 16 Apr 2008, at 15:10, Andrew Selder wrote:> > I was wondering what the community thought about an extension to the > associations mechanism which allowed declarations like: > > class Game < AR::Base > > has_two :referees > > end > > I have run across this situation fairly frequently. An object has a > defined number of subobjects of a particular type. In this situation I > don''t necessarily want to use habtm or has_many :through. The join > table just adds overhead to things like validation and ensuring that > there are not more than 2 referees attached to the game, etc. >I can''t say I''ve felt the need for something like this very often. But stick in a plugin and who knows, it might take off! Fred> This would be implemented db fields like referee_1_id, > referee_2_id,etc.. > > This approach simplifies forms and object creation in the contexts > where it is appropriate. > > If I had a list of referees, I could just do a collection_select for > each referee, rather than having to worry about link up other records > through a join table. > > Obviously this approach only applies to situations where there are a > defined number of subobjects, but I find this to be a fairly common > occurrence. > > Thoughts, comments? > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I''m with Fred: I haven''t really needed something like this but I can see the value of it. If you were gonna roll your own plugin for this, I''d suggest generalizing it a bit more. Maybe something like: has_some :referees, :count => 2 Then it would look for referee_1_id and referee_2_id, just like you wrote. But then you could dynamically define the number. Of course, it occurs to me that you are very tightly wedded to the DB in this case. I.e. if you want to change to three referees, you''d need to update the DB to add another FK field. And, the "has_many" or "has_one" puts the FK on _other_ table. It''s "belongs_to" that puts the FK on the current table. So maybe a better way to think about this is that it uses a normal has_many or habtm relationship but adds some constraints on it. I.e. if I set :count => 2, then trying to add a 3rd to the association would fail. Just some thoughts off the top of my head. -Danimal On Apr 16, 8:22 am, Frederick Cheung <frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 16 Apr 2008, at 15:10, Andrew Selder wrote: > > > > > > > I was wondering what the community thought about an extension to the > > associations mechanism which allowed declarations like: > > > class Game < AR::Base > > > has_two :referees > > > end > > > I have run across this situation fairly frequently. An object has a > > defined number of subobjects of a particular type. In this situation I > > don''t necessarily want to use habtm or has_many :through. The join > > table just adds overhead to things like validation and ensuring that > > there are not more than 2 referees attached to the game, etc. > > I can''t say I''ve felt the need for something like this very often. But > stick in a plugin and who knows, it might take off! > > Fred > > > This would be implemented db fields like referee_1_id, > > referee_2_id,etc.. > > > This approach simplifies forms and object creation in the contexts > > where it is appropriate. > > > If I had a list of referees, I could just do a collection_select for > > each referee, rather than having to worry about link up other records > > through a join table. > > > Obviously this approach only applies to situations where there are a > > defined number of subobjects, but I find this to be a fairly common > > occurrence. > > > Thoughts, comments?--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 16, 10:10 am, Andrew Selder <asel...-ee4meeAH724@public.gmane.org> wrote:> I was wondering what the community thought about an extension to the > associations mechanism which allowed declarations like: > > class Game < AR::Base > > has_two :referees > > end > > I have run across this situation fairly frequently. An object has a > defined number of subobjects of a particular type. In this situation I > don''t necessarily want to use habtm or has_many :through. The join > table just adds overhead to things like validation and ensuring that > there are not more than 2 referees attached to the game, etc.You are going to have to add "belongs_to_many" as well as "has_two"... if your game table has referee ids in it, then a game belongs_to a referee (not what you would expect, but that''s the way it is). The problem will come in when you say referee.game = somegame (or referee.games << game) or game.referees << referee, because a referee has_two (or five, whatever) games. Which column should these operations reference and change in the games table? In other words, if you assign a referee to a game, which of the already assigned referees should be replaced? It''s going to get ugly quick: you''ll have to have some kind of either pre-named function to do that for you (that would be hardcoded), or pass in a block. It''s a lot of work for a thin veneer of syntactic sugar... unless you have 10 or 20 of something, you really just need to write the 10 lines of code. This is probably why this feature doesn''t exist. Either you would have to break bi-directional referencing between your models (clearly not optimal), or write the replacement policy yourself (what you are having to do now anyway). It''s just not something where there is really only one correct way to do it. The same applies to modifying habtm with a :limit parameter or something like that, which if you had to do it some way, that''s what I would use, and throw an exception if you try to add too many things. I.e. force the user to take a referee away before adding if there are already two. Here''s the proper (IMO) way to do it: :habtm :referees do def addreferee (guard against too many referees) end #I have never tried this, but you might be able to overload operators using this def <<(ref) end end or: :habtm :referees, :before_add => :validate_refs def validate_refs() #Check count end In the Rails RDocs, checkout http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html. Relevant sections are "Association Callbacks" and "Association Extensions". If you do decide to write a plugin, this is probably the file to look at and mimic (probably using one of the methods above to modity HABTM relationship with a :limit parameter). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Hello, you could simply put in your Game model : belongs_to :referee_1, :class_name => ''Referee'' belongs_to :referee_2, :class_name => ''Referee'' But the problem is in the Referee model, what you would want is : has_one :game but that doesnt work because you have in fact two possible columns for the foreign key in the games table, leading to all the problems "Clever Neologism" mentionned. Now if you want to be able to get the game the referee is assigned to (but ONLY in read mode), you could put in your Referee model : def game Game.find(:first, :conditions=>"referee_1_id = "+id.to_s+" or referee_2_id = "+id.to_s) end of course the language itself doesn''t make it read only... so be careful :) -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---