Ruby on Rails Friday, July 29, 2011

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 to http://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

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_record/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 <nrf@ca-flower.com> 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:

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 <nrf@ca-flower.com> 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 rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://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 rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://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 rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://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 rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.

No comments:

Post a Comment