# The M in ORM

**URL:** <https://www.ruby-forum.com/t/the-m-in-orm/193636>\
**Category:** Rails\
**Created:** [August 20, 2010, 9:24pm UTC](https://www.ruby-forum.com/t/the-m-in-orm/193636 "2010-08-20T21:24:45Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![tutiplain](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/77aa72/32.png) [@tutiplain](https://www.ruby-forum.com/u/tutiplain)\
**Post date:** [August 20, 2010, 9:24pm UTC](https://www.ruby-forum.com/t/the-m-in-orm/193636/1 "2010-08-20T21:24:45Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![tutiplain](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/77aa72/32.png) [@tutiplain](https://www.ruby-forum.com/u/tutiplain)\
**Post date:** [August 20, 2010, 9:56pm UTC](https://www.ruby-forum.com/t/the-m-in-orm/193636/2 "2010-08-20T21:56:13Z")

</div>

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](http://www.marnen.org)  
removed\_email\_address@domain.invalid

---

<div class="post-metadata">

**Author:** ![tutiplain](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/77aa72/32.png) [@tutiplain](https://www.ruby-forum.com/u/tutiplain)\
**Post date:** [August 21, 2010, 12:07am UTC](https://www.ruby-forum.com/t/the-m-in-orm/193636/3 "2010-08-21T00:07:40Z")

</div>

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](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.

> **[lambda { }](http://ruby-lambda.blogspot.com/)**
>
> lambda { put(self).in(:pipe).and.call() }