Topic: Best way to build database structure?

I'm just starting out (with Rails 3.0), and am confused by the multiple ways to accomplish the same task of creating migrations. As I understand it so far, there are at least two methods to create the schema and the associated scaffold:

Method 1:
rails generate scaffold <object name> <field name :datatype> ...
[change app/model/<fieldname>.rb with linking e.g., has_many: <child obj> or belongs_to: <parent>]
rake db:migrate

Method 2:
rails generate migration <collection name>       {note: collection name = plural of the object name }
[edit the migration and add the schema commands]
rake db:migrate
rails generate scaffold <object name> <controller name>

Questions:
Which is the best way? (easiest to understand, least amount of editing magic files, etc.)
Is there another method that's better?
Which is the 'standard' way?
In Method 2, how & where do we put the relationship commands?

Re: Best way to build database structure?

Method 2 is primarily used for making alterations to your existing schema.

Example:
1. Create a model with attributes using 'rails g scaffold person name:string age:integer dob:integer'.
2. I go ahead a migrate those changes using 'rake db:migrate'.
3. I realize I made a mistake, dob should be type 'date', not 'integer' so I would create a migration to fix this using 'rails g migration change_dob_type_in_people'.
4. I would then edit /db/migrate/<DATE>_change_dob_type_in_people and add 'change_column :people, :dob, :date' to the 'self.up' method.
5. Migrate your changes using 'rake db:migrate' and now your datatype of dob would be correct.

In general, I believe you just want to name migrations something descriptive that help you understand what they do from their name so you don't have dig into them.

Hope that helps.

Re: Best way to build database structure?

You have a number of automatic generators available
1) Scaffold does everything and is the one will find yourself using the most.
It will create the migration, the controller with all the standard crud actions, the routes, all the test files, the model, the views that the controllers actions will use and lastly the helpers.

2) Migration generation on it's own is really for updating the structure of, and data in, existing tables. (You'll get a creation migration with the scaffold).

3) When you have more experience with rails you'll find yourself very rarely finding use for the other generators.

4) Well...
You have a lot to get your head round so I'll not go into them but if you find yourself getting curious then have a look here
http://wiki.rubyonrails.org/rails/pages … generators

What you want and what you need are too often not the same thing!
When your head is hurting from trying to solve a problem, stop standing on it. When you are the right way up you will see the problem differently and you just might find the solution.
(Quote by me 15th July 2009)

Re: Best way to build database structure?

Yes, thanks!

But this begs another related question. Let's say I used Method 1 to create a model, but forgot to add the associations before migrating. How do I add them after? That is, I did:

rails generate scaffold some_child_item name:string description:string
rake db:migrate

Oops, I forgot to modify app/model/child_item.rb with the following, before migrating:
     belongs_to: parent_item

How can I fix this?  Thanks in advance for your help!

Re: Best way to build database structure?

You just add the belongs_to and the has_many associations to the model which you have to do anyway regardless of the method used to generate in the first place so it makes no difference.

If however you forgot to add the foreign key to the belongs_to model then you would have to either create a new migration to add that column to the database table or migrate your database back one version and add the column in to the create migration as described by jmesserer in post #2
Which way you choose depends totally on you.
If you have data in that table that you would loose by migrating back, manually editing the migration file then migrating normally again then you would be better off to create a new migration to add the column.

It sounds far more complex than it really is. Once you get used to these scenarios you will find that it is actually really really simple especially when compared to other languages.

You need to get used to editing the migration files anyway so you can set up indexes, specify default values for columns and provide constraints
e.g.

class CreatePlugins < ActiveRecord::Migration
  def self.up
    create_table :plugins do |t|
      t.boolean :available, :default => false
      t.string :name
      t.text :description
      t.decimal :price, :precision => 8, :scale => 2, :default => 0
      t.string :plugin_type, :limit => 10
      t.text :terms_and_conditions

      t.timestamps
    end
  end

  def self.down
    drop_table :plugins
  end
end

Note the available, price and plugin_type entries have been manually edited prior to running rake db:migrate to provide
1) a 10 character limit on the size of the plugin_type column
2) Default the price to a value of 0 and set the column to be a maximum of 8 digits with 2 decimal places
3) Set the available column to default to a value of false
There are many more things you need to know but just take it slowly, experiment, read some books (AWDWR), check out the api docs and have some fun.

Hope that makes things clearer for you.

What you want and what you need are too often not the same thing!
When your head is hurting from trying to solve a problem, stop standing on it. When you are the right way up you will see the problem differently and you just might find the solution.
(Quote by me 15th July 2009)

Re: Best way to build database structure?

Yes, that clears it up. Thanks!