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?
--
Posted via http://www.ruby-forum.com/.
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
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 marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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 http://ruby-lambda.blogspot.com/ On Aug 20, 3:24 pm, tuti plain <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> 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. 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.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.