On Jul 29, 9:06 am, Rick & Nellie Flower <[email protected]> wrote: > Chris -- > > one more question if you don't mind too much! So, I blew away everything and > started over this > time using just the command line tools w/o fiddling around (at least outside > of adding the enum > pieces -- which seem on the surface like they might plug into the > generator).. Below are the commands I use and works (sort-of) when using the > web-interface tohttp://localhost:3000/users/new > > However, I don't believe it's creating the associations correctly -- the > "has_one" is incorrect as it's > kicked out when issuing the initial migrate to setup the database.. Do I > need to put the has_one > in by hand or is my syntax messed up? I was looking over the api-docs and > thought i had it right > but perhaps not. Below are the commands I issued : >
> 1) rails new test > 2) rails generate scaffold user address:has_one acct_locked:boolean > family_id:integer is_profile_setup:boolean last_login:datetime > password:string security_question:string security_answer:string > username:string type:string > 3) rails generate model address user:references street:string city:string > state:string zip:string email:string phone:string > 4) bundle exec rake db:migrate has_one doesn't belong in your migration/scaffold stuff. Add it to the model later on. (belongs_to/references is the exception to this, because user belongs_to :blah actually requires adding a column to the users table whereas user has_one :blah doesn't) Fred > > I get this on step #4 above : > rake aborted! > An error has occurred, this and all later migrations canceled: > > undefined method `has_one' for > #<ActiveRecord::ConnectionAdapters::TableDefinition:0x007fd88525e148> > /Users/nrf/.rvm/gems/ree-1.8.7-2011.03/gems/activerecord-3.0.9/lib/active_r > ecord/connection_adapters/abstract/schema_definitions.rb:326:in > `method_missing' > > Ugg.. > > On Jul 28, 2011, at 11:50 PM, Chris Kottom wrote: > > > > > If you want to do revisions on existing tables (adding columns, changing > > data types, etc.) you can use migrations for that as well. Experiment on > > the command line with patterns like: > > > rails g migration add_columns_to_addresses column_1:string column_2:integer > > ... > > rails g migration remove_columns_from_addresses column_1:string > > column_2:integer ... > > > The generator will try to figure out what you're attempting to do if you > > give it some basic instructions and if what you want to do isn't too > > complicated. > > > On Fri, Jul 29, 2011 at 8:35 AM, Rick & Nellie Flower <[email protected]> > > wrote: > > Thanks for the reply Chris.. > > > I'll switch away from Camelcase.. I use that at work all day long (C++) so > > I'm used to looking at > > it. > > > I initially used the generator but when revising tables it didn't want to > > run anymore complaining > > some of the files were already there -- which is why I resorted to > > hand-edits. I'll do some more > > reading on what you suggested.. Thx! > > > -- Rick > > > On Jul 28, 2011, at 11:22 PM, Chris Kottom wrote: > > >> Are you not using generators for the initial creation of your model and > >> migration source files? I'm asking because I think I can count on one > >> hand the number of times I've ever written out a create_table function > >> myself. Your inputs from the command line should do all this for you > >> along with some of the work of setting up your model associations (e.g. > >> the belongs_to call in your Address class definition) and save you some > >> effort. If you're using the generators properly, you may never have to > >> touch the migration files for simpler applications. > > >> rails g scaffold user acctLocked:boolean familyId:integer > >> isProfileSetup:boolean ... > >> rails g model address user:references address:string city:string ... > > >> For more info: > >>http://guides.rubyonrails.org/getting_started.html > >>http://guides.rubyonrails.org/command_line.html#rails-generate > > >> One other small thing: you're writing your variable names using camel case > >> (lowerCaseWithCapitalsIndicatingWordBoundaries) whereas the more widely > >> recognized Ruby convention is to use all_lower_case_with_underscores. I > >> left your variable names as-is in the sample code above, but if it's code > >> that anyone else will ever see or work on, you might consider changing it. > > >> On Fri, Jul 29, 2011 at 4:43 AM, Rick & Nellie Flower <[email protected]> > >> wrote: > >> Ok.. Still working on this stuff.. I've got the t.reference in the > >> migration for the address class and moved the belongs_to and has_one in > >> the model classes as indicated (I didn't notice that!). > > >> I noticed in the association-basics that I should be putting a > >> create_table function (if that's what > >> it's called) in the CreateUsers class for Migrations but I'm concerned > >> about doing that since I'll be using the address class on more than just > >> the 'users' class -- does it really belong there or ?? > >> Perhaps I'm overthinking this.. ?? > > >> Below are the two class definitions for both the model & migration : > > >> class Address < ActiveRecord::Base > >> belongs_to :user > >> belongs_to :organization > >> belongs_to :supplier > >> end > > >> class CreateAddresses < ActiveRecord::Migration > > >> def self.up > >> create_table :addresses do |t| > >> t.string :address > >> t.string :city > >> t.string :state > >> t.string :zip > >> t.string :email > >> t.string :phone > >> t.references : users > > >> t.timestamps > >> end > >> end > > >> def self.down > >> drop_table :addresses > >> end > >> end > > >> ================================= > >> class User < ActiveRecord::Base > >> enum_attr :accountType, %w(regular admin site_admin), :init=>:regular > > >> has_one :name > >> has_one :address > >> has_one :organization > > >> end > > >> class CreateUsers < ActiveRecord::Migration > > >> def self.up > >> create_table :users do |t| > >> t.boolean :acctLocked > >> t.integer :familyId > >> t.boolean :isProfileSetup > >> t.datetime :lastLogin > >> t.string :password > >> t.string :securityQ > >> t.string :securityA > >> t.string :username > >> t.enum :accountType > > >> t.timestamps > >> end > > >> create_table :a > >> end > > >> def self.down > >> drop_table :users > >> end > >> end > > >> -- > >> 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 > >> athttp://groups.google.com/group/rubyonrails-talk?hl=en. > > >> -- > >> 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 > >> athttp://groups.google.com/group/rubyonrails-talk?hl=en. > > > -- > > 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 > > athttp://groups.google.com/group/rubyonrails-talk?hl=en. > > > -- > > 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 > > athttp://groups.google.com/group/rubyonrails-talk?hl=en. -- 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.
