Now in rails we can use
t.string instead of t.column
using t.string is easy.But
t.column is a deprecated feature?
any other advantage of using t.datatype other than easiness.
Is there any way to convert all current migrations to new style easily.
t.column is not deprecated. You can use it without losing any sleep. The t.string syntax is just a "sugar" on top of the good old t.column.
1) sed. :)
2) Do you need to convert them? If you have schema.rb checked in as advised (or even a local copy somewhere), that should represent the current state of the database, right? If you do a "rake db:schema:dump" that should set you up with all the migrations up to that point in one schema.rb file, then you can go from there.
Related
On my migration file I have a number of new fields creation.
create_table :mytable do |t|
t.string :my_field, null: false
.........
And I am getting the following
Metrics/AbcSize: Assignment Branch Condition size for change is too high. [<1, 17, 0> 17.03/17]
What is the proper way to avoid that?
It's a common practice to exclude the db folder in your .rubocop.yml.
AllCops:
Exclude:
- 'db/**/*'
Most of the time we Ignore ./db folder in rubocp.yml file. Other than that we can disable cops for a specific block of code. Here is the answer Rubocop, how to Disable/Enable cops on blocks of code
I recently looked at my schema.rb file and was alarmed to find that certain columns that do exist in my database do not appear, and some tables are missing entirely. The missing columns were added to the database through "def change add_column" migrations, though some columns that were added in that way do appear as expected in schema.rb.
On closer inspection, I realized that schema.rb has not been updated since I created the Users table.
20151019205241_create_users.rb:
class CreateUsers < ActiveRecord::Migration
def change
create_table :users do |t|
t.string :name
t.string :email
t.timestamps null: false
end
end
end
This has not caused an issue for me in practice, but I thought schema.rb was supposed to be kept automatically updated, and that it would be important to have it updated in order to recreate the database. Can anyone help me figure out why it would not be updating?
One possibility is that it stopped being updated when I switched my database from sqlite3 to postgresql. I don't remember exactly, but I think the timing makes sense.
You can use rake db:schema:dump to re-create the file from the current database structure.
Schema file is independent from the driver so migrating from sqlite3 to PostgreSQL shouldn't matter. Make sure that version for definition in the file is not greater than current the current date. You can also add the whole file to the question's snippet.
I am working very first time on Rails Application. I am using Rails 4. As per tutorials and books I used Rails migrate command to generate initial schema. After that I called rake db:migrate. The message says table created but when I go to db/development.sqlite3 I find no table at all.
Following is the code of Migration File
class CreateEvents < ActiveRecord::Migration
def change
create_table :events do |t|
t.string :title
t.text :summary
t.integer :total_impacts #added later but does not reflect in db
t.integer :current_status #added later but does not reflect in db
t.timestamps
end
end
end
What steps am I missing?
Since I am on early stages of Database I rather called db:schema:load after making changes in schema.rb file.
I guess add_column should work too but not sure.
After reading the comments, I assume that the table was successfully created but that it's only a problem with the :total_impacts and :current_status columns.
If you run a migration once, the database knows that it's already been through it and won't run it again unless specified explicitly (rake db:migrate VERSION=...).
So if you write a migration, run it, then update it and try to run it again, the stuff you've just added (like a new column) won't appear in your database (because the migration has already been run in the database point of view).
If you realize after running the migration that you forgot some things, you have two options:
You can write another migration for the things you want to add/delete and run it. (Easy stuff).
You can rollback the migration (play the down part), edit it and run it again (play the up part). This one can be a bit more tricky depending on when you realize your mistake (has some data related to that migration already been added? etc).
Let's say I have a migration that creates a table 'pages' , this is my migration:
class CreatePages < ActiveRecord::Migration
def up
create_table :pages do |t|
t.string "name" , :limit => 50
t.integer "permalink"
t.integer "position"
t.timestamps
end
end
def down
drop_table :pages
end
end
and that I've created the appropriate migration file X_create_pages.rb and ran it(the table is created in the database).
Now after a few days I realize the structure isn't complete and I need to add another column to my pages table .
What is the best practice , do I create a new migration file with add_column method or do I just change the current migration file's up method -e.g just add my columns to the up method (and then move down a version and then up again - so to run the up method?)
The practice should be you create a new migration to add the new column. This becomes the simplest and risk free path. Of course, we can talk about unseen circumstances!
Updating original migration files should not be used after application is released to production; at least this is what the practice should be. But, this also depends on applications, if you don't have a table that is referenced elsewhere then backing up the data, adding the column and restoring the data is also a possibility which is enabled by this approach of directly modifying the original migration file and rolling down that version and migrating up that version again.
While you are on development, the choice I guess is yours. You could choose either!
Once a migration has been checked into source control it shouldn't be changed.
Modifying a migration on your development environment providing it hasn't been checked into source control is perfectly fine.
Once a migration has been checked in it may have been run by your team mates on their development environment or even been deployed and run in production.
Changing previously committed migrations is going to make you very unpopular in your team very quickly as team mates struggle to understand why their database schema is different from yours but all the migrations have been run.
Even if I never specify :null => false in my migrations that initially add columns to tables, rails still generates code in schema.rb that specifies the columns as having :null => false. Why is this? If I develop on my box, and then use rake db:schema:load on my production box, I'm going to get very different behavior!
Edit: Even if I delete schema.rb and run rake db:schema:dump, it still puts :null => false on the new schema even if it isn't defined like that in the actual database. It seems it can't tell whether or not a column is marked as allowing nulls. I'm using SQLite if that helps.
I really hate that this was so subtle, but the problem was I was using the sqlite3 gem instead of sqlite3-ruby. As soon as I corrected it in environment.rb, everything was better.
Reverting to ruby 1.8.7 did the trick for me.
No idea why though.