views:

396

answers:

4

I don't have a Rails environment set up and this is actually quite hard to find a quick answer for, so I'll ask the experts.

When Rails creates a table based on your "model" that you have set up, does Rails create a table that mirrors this model exactly, or does it add in more fields to the table to help it work its magic? If so, what other fields does it add and why? Perhaps you could cut and paste the table structure, or simply point me to a doc or tutorial section that addresses this.

+5  A: 

In ActiveRecord, models are created from database tables, not the other way around.

You may also want to look into Migrations, which is a way of describing and creating the database from Ruby code. However, the migration is not related to the model; the model is still created at runtime based on the shape of the database.

There are screencasts related to ActiveRecord and Migrations on the Rails site: http://www.rubyonrails.org/screencasts

Brad Wilson
That's weird because the video I saw of some guy demo'ing the awesomeness of Rails made changes to the model and it propagated those changes to the database. Or am I remembering wrong?
Ixion
I've only ever used ActiveRecord. Perhaps what you saw was a different data access system.
Brad Wilson
Ixion, you're probably thinking of the famous Blog in 15 Minutes video, which used Migrations to make changes in the database schema that were immediately reflected in the forms onscreen due to scaffolding being used.
Patrick McKenzie
DataMapper (a 'competitor' to ActiveRecord) takes the approach of describing the table in the model file directly. However DM is used more with Merb than with Rails. Maybe you saw a Merb/DM screencast?
webmat
+1  A: 

Here's the official documentation for ActiveRecord. It agrees with Brad. You might have seen either a different access method or a migration (which alters the tables and thus the model)

Vinko Vrsalovic
+6  A: 

If you're building a completely new application, including a new database, then you can build the whole back end with migrations. Running

ruby script/generate model User name:string

produces both a user.rb file for the model and a migration:

class CreateUsers < ActiveRecord::Migration
  def self.up
    create_table :users do |t|
      t.string :name

      t.timestamps
    end
  end

  def self.down
    drop_table :users
  end
end

You can see that by default the generate script adds "timestamps" for (created and last updated) and they're managed automatically if allowed to remain present.

Not visible, but important, is that an extra column, "id", is created to be the single primary key. It's not complusory, though - you can specify your own primary key in the model, which is useful if you're working with a legacy schema. Assuming you retain id as the key, then Rails will use whatever RDBMS-specific features are available for new key values.

Mike Woodhouse
+1  A: 

I have had a little experience moving legacy databases into Rails and accessing Rails databases from outside scripts. That sounds like what you're trying to do. My experience is in Rails databases built on top of MySQL, so your mileage may vary.

The one hidden field is the most obvious --- the "id" field (an integer) that Rails uses as its default primary key. Unless you specify otherwise, each model in Rails has an "id" field that is a unique, incremented integer primary key. This "id" field will appear automatically in any model generated within Rails through a migration, unless you tell Rails not to do so (by specifying a different field to be the primary key). If you work with Rails databases from outside Rails itself, you should be careful about this value.

The "id" field is a key part of the Rails magic because it is used to define Rails' associations. Say you relate two tables together --- Group and Person. The Group model will have an "id" field, and the Person model should have both its own "id" field and a "group_id" field for the relationship. The value in "group_id" will refer back to the unique id of the associated Group. If you have built your models in a way that follows those conventions of Rails, you can take advantage of Rails' associations by saying that the Group model "has_many :people" and that the Person model "belongs_to :group".

Rails migrations also, by default, want to add "created_at" and "updated_at" fields (the so-called "timestamps"), which are datetime fields. By default, these take advantage of the "magic" in the database --- not in Rails itself --- to automatically update whenever a record is created or modified. I don't think these columns will trip you up, because they should be taken care of at the database level, not by any special Rails magic.

don
The created_at and updated_at fields are handled in Rails, not through any database "magic". You can see this directly in the generated SQL.
ScottJ