On Jul 13, 7:31 am, RichardOnRails <[email protected]> wrote: > I built the migration: > class ExpensesVendorJoinTable < ActiveRecord::Migration > def self.up > create_table :expenses_vendor, :id=>false do |t| > t.integer :expenses_id > t.integer :vendor_id > t.timestamp :created_at > end > end >
That's setting yourself up for has_and_belongs_to_many (a single vendor can have multiple expenses and a single expense can have multiple vendors). Is that what you want ? (the earlier snippet from your models suggests no) > How do I modify my Expense.new from vendor-lookup via > <%# �...@vendors = Vendor.all -%> > <%# def name; Vendor.nickname; end -%> > <%#= f.collection_select(:vendor, :vendor_id, > @vendors, :id, :name) -%> > so that the user can select a vendor from a drop-down and only the > selected vendor's ID will be saved in the join-table, > rather than the vendor's name saved in the expense record. Assuming Vendor belongs_to :expense then f.collection_select :vendor_id, @vendors, :id, :name would do the trick - you're setting the vendor_id attribute of your object, using the collection of vendors named @vendors, the possible attribute values are given by their id and they should be displayed using their name (there is an example here: http://guides.rubyonrails.org/form_helpers.html#option-tags-from-a-collection-of-arbitrary-objects ) Fred > > This should be my last hurdle for this application. Any guidance will > be most appreciated. I didn't see an answer on the sites we've talked > about. > > Thanks in Advance, > Richard > > On Jul 12, 9:45 pm, Marnen Laibow-Koser <[email protected]> wrote: > > > > > 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-Koserhttp://www.marnen.org > > [email protected] > > -- > > Posted viahttp://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.
