The M in ORM

rubyonrails-talk
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,

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 Hsiao