Sorry that this question is not a proper one on this site, but I really thought that I needed to know how to do that, because in production environment, if I delete all data all the time when I delete a model, this should be a serious problem.
In detail
In case re-making the same named model,I mean after delete a model, then make the same named model.
It should be like
rails destroy model Name
and after that
rails g model Name
And usually errors occur in this case, we can basically fix the errors by using the command rails db:schema:load, but this command destroys whole data of an existing database, but I don't want to lose the data so I wonder if there are any other good ways for this.
Thanks
Normally, this should not affect your production database, since Ruby on Rails knows what migrations have run already and that's why you should use rails db:migrate to update your database.
If your production database has old entries that you want to reuse, you can also change the Active Record Migrations so that the affected table does not get dropped and recreated but altered instead.
Related
I am new to Ruby on Rails, so I have some confusion about rails migration.
I want to add a field on my user table, according to rails documentation is only possible by using
rails generate migration add_field_name_to_table_name field_name: type
Question
Is it possible to add fields to the existing database table without rails g migration in rails? Thanks...
The bigger question is why you need to do that. I mean to imply that whatever makes you think that you need to do this is wrong (I am pretty confident about it, assuming you are a new rails user). It is like you would leave your plane without a reason for a long-distance flight to travel by foot.
Answer:
You can do that by:
logging in to Postgres manually like rails db
then creating table manually the SQL way
then adding the table manually with correct columns in your schema.rb file
then creating a model manually
You still will have to repeat this every time this project is cloned anywhere else with no window for mistake. With migration, on the other hand, you will just need to do rails db:migrate
Happy Coding.
There are a number of questions here about adding columns to a model via rails migration files and a rake db:migrate.
In this case, however, the application is basically a CRUD on top of an existing SQL Server database that is generated by another application. That is, I don't control it. Those who do control the database have added several columns to a table.
What I need is for the Rails app to respect the changes made to the database without assuming it has full control over the table structures.
I've tried plugging the new fields into the model and controller files, but sql queries give TinyTDS errors saying the new fields don't exist. Queries by hand (via SQL Server Management Studio) work fine. What am I missing? Why doesn't Rails recognize the new fields when they appear in the table model?
UPDATE:
It turns out that the problem is more subtle than I though when asking the initial question. As background, this application is set up with two databases, one production, one development/test. They are both on the same SQL Server database server. What's actually happening with the missing columns is that the Rails app pulls from production no matter what environment I use. Even when I change both environments to use the same development database (in database.yml), the app continues to query the production database.
Perhaps this is a problem between Rails and SQL Server. I've cleared all caches and cleared all database connections, but it makes no difference. It seems that the Rails app is caching the database name and login info somewhere.
One day I'd like to get this fixed, but for now I'll simply move the development database to another server for testing.
ActiveRecord has a cache of the table fields. If you want to reset the cache for a model without restarting your application, you can do:
MyModel.reset_column_information
I want to create a Rails app but I have a question before start it.
I have defined a database model in paper (about 15 tables) and I don't know which is the best way to start the application:
Create the tables on database with my database client and after that in console do:
rake db:schema:dump
with this I will obtain the shema.rb and after that do a :
rake db:migrate
or
In console, one to one, create the models, edit them with an editor and do:
rake db:migrate
I think the first one is more quickly but the second I think is better from the point of view of rails.
I am bit confused about that, can anyone help me with this question?
Rails mean the only sure way to create a database for a new application - migration.
You can create a single migration for all of your application but such migration is not easy to roll back.
Therefore wise to create a migration for each table.
Normal situation when you have 100,500 migrations in the end. For that you get your application is ready for deploy to combat server.
Permitted the creation of migration through model and scaffold or independently.
Why not use a generator?
rails g model User first_name last_name age:integer email user_name
You don't need to specify type if it's string. This will generate model class and migration.
I think there may be varying viewpoints on this issue.
Also, it depends if you're using the rails built-in sqlite database.
However, assuming that you do use the default rails db configurations,
I personally prefer the second choice.
Later, you might want to change some parts in your tables.
If you follow the rails way of doing so, this process will be very easy and less confusing.
Also, you can always add custom ruby scripts for pre-loading with data.
Of course, other people might find the other way easier.
I have an existing database in which I am converting a formerly 'NULL' column to one that has a default value (and populating that with said default value). However, that value is an ID of a record I need to create. If I put this record in db/seeds.rb, it won't run because db/seeds.rb runs after migrations -- but the migration needs seed data. If I leave the record creation in the migration, then I don't get the record if I make a fresh database with db:load. Is there a better way other than duplicating this in both db/seeds.rb and the migration?
Thanks!
While I can understand your desire to stay DRY and not have to write this in both the migration and seeds.rb, I think you should write it in both places. Not just to make it work, but to accomplish different requirements related to your problem.
You need to ensure that your migration can execute properly regardless of external processes. That means you should put any code required within that specific migration. This isn't to accomplish anything besides making sure your migration executes properly. Suppose someone else tries to migrate without knowing you put part of the code in seeds.rb, it would be very difficult for them to figure out what's going on.
You can make db:load work properly by including similar code in seeds.rb. However, you should be evaluating the current state of your database in seeds.rb due to the fact that it runs after the migrations. So you can check to see if the column exists, and what the default value is etc. This means that if the migration ran and took care of everything, seeds.rb doesn't repeat work or modify values inappropriately. However, if the migration did not set these variables as expected, it is able to set the values.
I'd recommend looking at it as two separate issues so you can be more confident of each one executing successfully independent of one another. It also creates better maintainability for understanding by yourself or others of what's happening in the future.
In my opinion you should treat this in both db/seeds.rb and the migration.
The migration is used to get an existing database from an older version to another version while seeds.rb and schema.rb are used for a fresh database with the latest version.
I'm switching to RoR from ASP.NET MVC. Yeah, migrations are cool, but I do not need to use different databases in my web applications. Postgresql will do just fine.
So is it okay if I use PGAdmin to create and administer my databases and schema and avoid all these fancy migrate, rake etc?
Update
Thanks everyone! Now I better understand what migrations are, and why I should use them.
I don't think that's what migration means.
Migrations in rails (and in other frameworks) is a method by which you can use to update your database schema when there are multiple versions of the same database running
For example, you may have two databases, one running on your production server, and another running locally for development. After a few days of coding, your local development database may looks a bit different. With migrations, you can simply push your code to the production server and then run the migrations to automatically update your production database so it is up-to-date with the one you use locally for development.
So, to answer your question, Yes it is OK but you might not get a few of the migrations niceties when the time comes that you'll have to maintain multiple versions of your database.
Have to agree with charkit but one (rather two) important note why you should use migrations: Migrations don't make up the model definitions. They are stored seperately in a file schema.rb. This defines the rows and tables of your database. When looking into the file, you find these lines:
This file is auto-generated from the current state of the database. Instead of editing this file, please use the migrations feature of Active Record to incrementally modify your database, and then regenerate this schema definition.
The second reason is for testing: you can easily set up a test database to run all your tests against without the need to touch the "real" database. I know when developing, this is not a big problem but this will get more important after some time.
So, yes, it is possible to use PGAdmin to create all your database related stuff but you should not forget to always keep the schema file up to date and come up with a solution for testing.
With migrations you're able to develop your database schema in Ruby and this is usually database indpendent.
In short, spend the 20 minutes or so to really get migrations and the value they add. Then determine whether or not you want to ditch them. Strangely for me I learned Rails before I started my first MVC project; one of the things I missed most was migrations.
From a technical standpoint you should be fine without them.