RichardOnRails wrote:
> On Jul 12, 8:24�pm, Marnen Laibow-Koser <[email protected]> wrote:
>> RichardOnRails wrote:
>> > I just added these linkage statements to my Expense and Vendor models,
>> > respectively.
>>
>> Which? �You neglected to say.�
>
> Change the Expense model:: app\models\expense.rb
> class Expense < ActiveRecord::Base
> belongs_to :vendor # Added
> end
>
> Change the Vendor model:: app\models\ vendor.rb
> class Vendor < ActiveRecord::Base
> has_many :expenses # Added
>
> def name
> #{qbname} # QuickBooks name
> end
> end
#{} syntax is only valid within double-quoted strings.
>
>> > webpage (http://www.railsforum.com/viewtopic.php?id=265).
>>
>> Why are you following tutorials from 2006, before Rails 1.0 even
>> existed?
>
> Because it was the simplest one I stumbled across.
Who cares how simple it is if it's obsolete?
[...]
>> > That leads me to think that I need to:
>> > 1. Create migration Add_Vendor_ID_to_Expense and then add column
>> > vendor_id of type integer, or something like that.
>> > 2. Create migration Add_Expense_ID_to_Vendor and then add column
>> > expense_id of type integer, or something like that.
>>
>> You don't need both.�
>
> Why not? And if not, does it matter which one I use?
The Rails associations documentation explains which one you need.
Perhaps you should go read that (it's the docs for the module that
contains the has_many and belongs_to methods).
>
>> > 3. Create migration Create_Expense_Vendor_Table and then add
>> > expense_id and vendor_id columns.
>>
>> You may not need this at all.�
> Really. You mean Active Record is smart enough to decipher this from
> the mere fact that I added those one-liners to the respective models?
No, I mean that you don't need a join table in this case, for reasons
related to relational DB design and having nothing to do with Rails or
ActiveRecord at all.
I *would* however advise using the Foreigner plugin to put foreign key
constraints in the DB.
The fact that you're asking these questions makes me think that you know
very little about relational database design. So put aside Rails for a
day or two and go learn. In particular, learn about the proper use of
foreign keys, and about normalization, especially as far as the Third
Normal Form (3NF). Wikipedia has some excellent articles on these
topics.
>
>> And it should all be in one migration class if it represents one
>> conceptual change.�
> I thought of that but decided to go with my first thought.
...because...?
>
> Again, best wishes,
> Richard
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
--
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.
