The M in ORM

Rails
1

Hi everyone,

I am attempting to connect an already existing mysql database with
Rails. For This I can’t use the traditional “generate scaffold” and
“rake db:migrate” because (I think), I’ll loose the data already
existing in that database table. So what I did was, I generated a
scaffold for my table, and instead of running db:migrate, I added a
set_table_name to my model.

Of course, I get a bunch of errors whenever I do things like
Product.all, because I think my model’s properties are not properly
mapped to the database table columns. So I began poking around my rails
app rolder and found a file named schema.rb in the “db” folder inside my
app, with content like this:

create_table “users”, :force => true do |t|
t.text “username”
t.text “password”
t.text “email”
t.text “real_name”
t.datetime “created_at”
t.datetime “updated_at”
end

There were also some comments about not editing this file manually, but
to use migrations instead.

So the questions are: How does Rails know which properties from the
model to match to the database fields? What is the purpose of
db\schema.rb? And how, then, would you reccomend that I connect this
table to my Rails app?

2

tuti plain wrote:

Hi everyone,

I am attempting to connect an already existing mysql database with
Rails. For This I can’t use the traditional “generate scaffold” and
“rake db:migrate” because (I think), I’ll loose the data already
existing in that database table.

Not quite. What will happen when you try to run the migration is that
the DB will refuse to create a table with the same name as the one that
already exists.

So what I did was, I generated a
scaffold for my table, and instead of running db:migrate, I added a
set_table_name to my model.

Why use a scaffold at all? This is not a good use case for it. Just
hand-code what you need.

And why do you need set_table_name? Is the name of the table not
following Rails conventions?

Of course, I get a bunch of errors whenever I do things like
Product.all, because I think my model’s properties are not properly
mapped to the database table columns.

Why do you think that? What errors are you getting?

So I began poking around my rails
app rolder and found a file named schema.rb in the “db” folder inside my
app, with content like this:

create_table “users”, :force => true do |t|
t.text “username”
t.text “password”
t.text “email”
t.text “real_name”
t.datetime “created_at”
t.datetime “updated_at”
end

There were also some comments about not editing this file manually, but
to use migrations instead.

Right. The schema.rb file basically contains what Rails thinks your DB
should look like – you use rake db:schema:load to set up a new
installation, and you can use rake db:schema:dump to have Rails
regenerate the schema file from your DB (which is a very good idea in a
case liike yours, where you’ve got tables that weren’t created by
migrations).

So the questions are: How does Rails know which properties from the
model to match to the database fields?

You’re thinking about it backwards. Rails looks to see what fields are
in the DB table, then basically fakes properties of the same name on the
model class. So if it sees that the “users” table has a “first_name”
field, then it will make User.first_name and User.first_name= work as
expected.

What is the purpose of
db\schema.rb? And how, then, would you reccomend that I connect this
table to my Rails app?

I answered both these questions above, I think.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

3

I’m not sure if you are modifying a legacy Rails app or a legacy DB
schema.

If it is the latter, I suggest looking at Datamapper instead (http://
datamapper.org) since that will let you explicitly map fields from the
database to properties.

As for the former, I suggest playing it safe: take a mysqldump of the
existing database (I’m assuming it is in production) and load it to
your dev box; have your dev box version of the app connect to your
copy of the database. You can experiment and play with it without fear
of wiping out the data – since you have a snapshot, you can always
reload it from scratch.

Ho-Sheng H.