Rails - Jul 2009 - Quick simple check: Very simple relationship setup (newbish for sure.)

Been googling trying to understand belongs_to, has_one, etc

For this scenario: ''A Person has a single favorite color and has
multiple addresses. (Colors are reused across all the persons,
addresses are always unique only for one person)''

Would the following suffice? (not worrying about adding indexes yet.)

class Person < ActiveRecord::Base
  belongs_to :favorite_color, :class_name => "Color", :foreign_key
=> "color_id"
  has_many :addresses, :dependent => :destroy
end

class Address < ActiveRecord::Base
  belongs_to :product
end

class Color < ActiveRecord::Base
  #don''t need anything
end

The toughest thing conceptually to get a handle on was "belongs_to" on
something like Color. From an OO perspective a Person "has_one" Color,
but from reading the docs I see that belongs_to puts the foreign key
on that table in the class where you declare belongs_to so in the
above it belongs on Person. (From an OO perspective the Address
''belongs_to'' a Person makes sense.)

Here''s a diagram which might help with your model:

http://learn.kohanaphp.com/wp-content/uploads/2008/04/ruby-on-rails-data-relationships.png

Make sure you also check:

http://guides.rubyonrails.org/association_basics.html

===========
The best advice I can give you is to draw a complete diagram with all 
your models either on paper or a drawing board, or in a program (your 
choice).  Once you diagram the pattern you can write the relationship on 
the lines.

The reason why I say to do this goes much farther back than Rails when I 
worked with Crystal Reports.  Diagrams allow you to see the associations 
better.

Looking at what you provides so far let''s go ahead and diagram it 
exactly the way you wrote it and see what''s wrong here.  I''m
leaving off
activerecord base for sake of clarity...

class Person
  belongs_to :favorite_color, :class_name => "Color", :foreign_key
=>
"color_id"
  has_many :addresses, :dependent => :destroy
end

class Address
  belongs_to :product
end

class Color
  #don''t need anything
end

============================
First thing I don''t see is your relationship models for Product or 
FavoriteColor.  So, creating them based off what you wrote above I see:

class Product
  has_many :addresses
end

class FavoriteColor
  has_many :persons
  has_many :addresses, :through => :persons
end

But, you have class Address belonging to Product but your association 
for Person is stating that addresses belong to it.  Which does address 
really belong to?







-- 
Posted via http://www.ruby-forum.com/.

On Fri, Jul 10, 2009 at 3:58 PM, Älphä
Blüë<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:
> Looking at what you provides so far let''s go ahead and diagram it
> exactly the way you wrote it and see what''s wrong here.
 I''m leaving off
> activerecord base for sake of clarity...
>
> class Person
>  belongs_to :favorite_color, :class_name => "Color",
:foreign_key =>
> "color_id"
>  has_many :addresses, :dependent => :destroy
> end
>
> class Address
>  belongs_to :product
> end
>
> class Color
>  #don''t need anything
> end
>
> ============================>
> First thing I don''t see is your relationship models for Product or
> FavoriteColor.  So, creating them based off what you wrote above I see:
>
> class Product
>  has_many :addresses
> end
>
> class FavoriteColor
>  has_many :persons
>  has_many :addresses, :through => :persons
> end
I thought I could do:
belongs_to :favorite_color, :class_name => "Color", :foreign_key
=> color_id

Which tells it to use the Color class for favorite_color ? I don''t
want a FavoriteColor model, just Color. I could have just used:
class Person
   belongs_to :color
If I was content with a color_id column name for favorite color on Person.

> But, you have class Address belonging to Product but your association
> for Person is stating that addresses belong to it.  Which does address
> really belong to?
Well the reason I added Addresses ''belonging to" Product is so
that it
would put the FK product_id in the Address table.  I guess I should
just leave off belongs_to :person on the Address model?

And thanks for the links by the way.

But looking at the second link they show:

class Customer < ActiveRecord::Base
   has_many :orders, :dependent => :destroy
end

class Order < ActiveRecord::Base
   belongs_to :customer
end

How is that any different than my association for Person and Address
(which you said was wrong)?

class Person < ActiveRecord::Base
  has_many :addresses, :dependent => :destroy
end

class Address < ActiveRecord::Base
 belongs_to :product
end

It looks the same as it does in the doc, unless I''m missing something?

On Fri, Jul 10, 2009 at 4:40 PM,
Rick<rickcr-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On Fri, Jul 10, 2009 at 3:58 PM, Älphä
> Blüë<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
>
>> Looking at what you provides so far let''s go ahead and diagram
it
>> exactly the way you wrote it and see what''s wrong here.
 I''m leaving off
>> activerecord base for sake of clarity...
>>
>> class Person
>>  belongs_to :favorite_color, :class_name => "Color",
:foreign_key =>
>> "color_id"
>>  has_many :addresses, :dependent => :destroy
>> end
>>
>> class Address
>>  belongs_to :product
>> end
>>
>> class Color
>>  #don''t need anything
>> end
>>
>> ============================>>
>> First thing I don''t see is your relationship models for
Product or
>> FavoriteColor.  So, creating them based off what you wrote above I see:
>>
>> class Product
>>  has_many :addresses
>> end
>>
>> class FavoriteColor
>>  has_many :persons
>>  has_many :addresses, :through => :persons
>> end
>
> I thought I could do:
> belongs_to :favorite_color, :class_name => "Color",
:foreign_key => color_id
>
> Which tells it to use the Color class for favorite_color ? I don''t
> want a FavoriteColor model, just Color. I could have just used:
> class Person
>   belongs_to :color
> If I was content with a color_id column name for favorite color on Person.
>
>
>> But, you have class Address belonging to Product but your association
>> for Person is stating that addresses belong to it.  Which does address
>> really belong to?
>
> Well the reason I added Addresses ''belonging to" Product is
so that it
> would put the FK product_id in the Address table.  I guess I should
> just leave off belongs_to :person on the Address model?
>


-- 
Rick R

Rick wrote:
> And thanks for the links by the way.
> 
> But looking at the second link they show:
> 
> class Customer < ActiveRecord::Base
>    has_many :orders, :dependent => :destroy
> end
> 
> class Order < ActiveRecord::Base
>    belongs_to :customer
> end
> 
> How is that any different than my association for Person and Address
> (which you said was wrong)?
> 
> class Person < ActiveRecord::Base
>   has_many :addresses, :dependent => :destroy
> end
> 
> class Address < ActiveRecord::Base
>  belongs_to :product
> end
> 
> It looks the same as it does in the doc, unless I''m missing
something?
> 
> On Fri, Jul 10, 2009 at 4:40 PM,
Rick<rickcr-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> end
>>>
>>> end
>>
>>> But, you have class Address belonging to Product but your
association
>>> for Person is stating that addresses belong to it. �Which does
address
>>> really belong to?
>>
>> Well the reason I added Addresses ''belonging to" Product
is so that it
>> would put the FK product_id in the Address table. �I guess I should
>> just leave off belongs_to :person on the Address model?
>>
> 
> 
> 
> --
> Rick R
Hi Rick,

Thanks for looking at the links and thanks for the clarifications.  I 
missed your Color class association so that part is fine.

Looking at the Customer - Order association you placed here..

Customer --> Has Many --> Orders
Orders --> Belongs to --> Customer

That''s a correct association...

Now look at yours:

Person --> Has Many --> Addresses
Address --> Belongs to --> (PRODUCT)?

Notice there''s no correct association here...

Anytime you you have a name_id in any of your tables, rails 
automatically knows it''s a foreign key once you apply the association.

Person has many addresses
Address belongs to person
Product has many addresses
Address belongs to product

That sound about right?

Class Person
  has_many  :addresses, :dependent => :destroy
end
Class Address
  belongs_to  :person
  belongs_to  :product
end
Class Product
  has_many  :addresses
end



-- 
Posted via http://www.ruby-forum.com/.

Using what I posted above you need to have the following:

In your Address model you need to have a

person_id
product_id

If you want these foreign keys to be different you can do the following:

Class Address
  belongs_to  :person
  belongs_to  :product  :foreign_key => uniquesomething_id
end

Whatever foreign_key you use, needs to be setup correctly in the table 
which belongs to the other table.

It really comes down to whatever you want to do and that''s why 
diagraming is good because it allows you to see what you have before you 
implement things to make sure they work well.
-- 
Posted via http://www.ruby-forum.com/.

UGGHHHH! I feel so bad.

Stupid copy and paste error! Amazing I could be  staring at something
and not even see it.

I was translating something else into Person/Color/Address from what I
was working with "Product" and totally screwed up and put Product down
since it was on my mind instead of Person.

So sorry for the confusion! And thanks so much for your patience and
help. I can''t believe I was mentally translating Product into Person
in my head:)

I meant to have:

class Address < ActiveRecord::Base
     belongs_to :product
 end

That makes more sense now I bet:) Apologies again.





On Fri, Jul 10, 2009 at 5:30 PM, Älphä
Blüë<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
>
> Using what I posted above you need to have the following:
>
> In your Address model you need to have a
>
> person_id
> product_id
>
> If you want these foreign keys to be different you can do the following:
>
> Class Address
>  belongs_to  :person
>  belongs_to  :product  :foreign_key => uniquesomething_id
> end
>
> Whatever foreign_key you use, needs to be setup correctly in the table
> which belongs to the other table.
>
> It really comes down to whatever you want to do and that''s why
> diagraming is good because it allows you to see what you have before you
> implement things to make sure they work well.
> --
> Posted via http://www.ruby-forum.com/.
>
> >
>


-- 
Rick R

Ha i did it again sorry:

class Address < ActiveRecord::Base
    belongs_to :person #!!!!!!!!!!!!!!!
  end

Ok it''s Friday I need to go away !


On Fri, Jul 10, 2009 at 5:33 PM,
Rick<rickcr-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> UGGHHHH! I feel so bad.
>
> Stupid copy and paste error! Amazing I could be  staring at something
> and not even see it.
>
> I was translating something else into Person/Color/Address from what I
> was working with "Product" and totally screwed up and put Product
down
> since it was on my mind instead of Person.
>
> So sorry for the confusion! And thanks so much for your patience and
> help. I can''t believe I was mentally translating Product into
Person
> in my head:)
>
> I meant to have:
>
> class Address < ActiveRecord::Base
>     belongs_to :product
>  end
>
> That makes more sense now I bet:) Apologies again.
>
>
>
>
>
> On Fri, Jul 10, 2009 at 5:30 PM, Älphä
> Blüë<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
>>
>> Using what I posted above you need to have the following:
>>
>> In your Address model you need to have a
>>
>> person_id
>> product_id
>>
>> If you want these foreign keys to be different you can do the
following:
>>
>> Class Address
>>  belongs_to  :person
>>  belongs_to  :product  :foreign_key => uniquesomething_id
>> end
>>
>> Whatever foreign_key you use, needs to be setup correctly in the table
>> which belongs to the other table.
>>
>> It really comes down to whatever you want to do and that''s why
>> diagraming is good because it allows you to see what you have before
you
>> implement things to make sure they work well.
>> --
>> Posted via http://www.ruby-forum.com/.
>>
>> >>
>>
>
>
>
> --
> Rick R
>


-- 
Rick R