mlittle wrote: > Another newbie question by me... First, do yourself a favor and not start off by advertising your "newbie" status. Trust that experienced programmers will know right away where you are in your learning by reading your question.
Before attempting to answer this question I would like some confirmations. Read on... > I have this: > > class User < ActiveRecord::Base > ... > has_one :book, :through => :library > ... > end Are you wanting to say here that a user can only check out one book at a time from the library? > class Library < ActiveRecord::Base > has_one :book, :dependent => :destroy > end And a library can only ever contain one book? > class Library < ActiveRecord::Base > belongs_to :library > validates_existence_of :library > end Did you mean to define Book here instead of reopening the Library class and adding stuff to it? Assuming you meant Book it seems fine for a book to belong to a library. There is no validates_existence_of. Assuming you meant validates_presence_of :library: I'm even a little bit torn on this one, but I validate the presence of the foreign key (:library_id in this case) rather than validate the association. From my experience so far it seems to make for cleaner test scripts and also does not directly depend on the actual association object making model tests easier to manage. > I just don't know what my route will look like. Once you get your model actually right your routes will make sense. > Any help or suggestions? Are my models correct in how I used the has_one > :through Keep this in mind as a general rule of thumb: The reason has_one exists is for creating one-to-one associations. Thing A can have only one B and thing B can only ever have one A. So why would you ever need one-to-one associations? Can't you just add all the needed fields to one table? Technically the answer is "Yes you can." However, there are some very useful and practical uses for one-to-one associations. - Sometimes groups of fields, which actually are functionally depend on the primary key of a row, are related in other ways and are good candidate to be broken out into a separate table. - Often a table may contain a set of "optional" fields that don't need to have values for every row in a table. These can be broken out to a separate table for effeciency's sake and to clean up all those NULLs you would see if there was only one table. - There are also cases where a table may contain a large character or binary blob. Most of the time it's convenient to just use the wildcard when selecting data: (select * from my_table;). If that table contained a column of type (TEXT or BLOB). Then you're going to suffer a significant performance hit. That could be fixed by always specifying the list of columns with something like: (select Col1, Col2, Coln from my_table;), but you could also use a one-to-many and put the TEXT or BLOB in a separate table. Then (select * from my_table;) would only fetch the foreign key (i.e. my_blob_id), which is a simple integer and you won't suffer the performance hit. When you actually want to get the large TEXT or BLOB you can either grab them individually thought the association, or include them if you need to grab a list of objects: @posts = Post.find(:all, :include => :post_narrative). So why has_one and not belongs_to? Well to answer this you need to consider how a one-to-on association is built in Rails. It is really just like a one-to-many association with a validation that only allows one object to be associated on the "many" side. So think of has_one as a "special" has_many than includes the proper validation (to ensure one-to-one) and also provides the one object instead of an array containing the one object. So which side gets the has_one? Well that's easy to answer as well: use belongs_to on the model that contains the foreign key and use has_one on the model that doesn't. You get to decide which model should get the foreign key. Usually objects have a natural association that makes that fairly easy. Say that a Person can only have one Residence (within this design). You wouldn't think about a Person belonging to the Residence. You would rather say the Residence belongs to the Person. So Residence would get the foreign key, an hence the belongs_to :person. So then Person gets the has_one: residence. I apologize for the long reply. Maybe this belongs_to :blog. -- 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
