rails db:migrate?In a Rails project, what is the main effect of running the command rails db:migrate?
Think about what migrations are for and what the db/migrate folder contains.
Running rails db:migrate applies all migration files that have not yet been run. These files describe changes to the database schema, such as creating or altering tables.
Which of the following migration snippets correctly adds a string column named username to the users table?
Remember the order of arguments for add_column is table name, column name, then type.
The correct syntax is add_column :table_name, :column_name, :type. Option B follows this exactly.
Consider this migration code:
class AddAgeToUsers < ActiveRecord::Migration[6.1]
def change
add_column :users, :age, integer
end
endWhy will this migration cause an error when running rails db:migrate?
class AddAgeToUsers < ActiveRecord::Migration[6.1] def change add_column :users, :age, integer end end
Check the data type argument in add_column.
In Rails migrations, data types must be symbols. Using integer without a colon causes a NameError because Ruby treats it as a variable or method name.
After running rails db:migrate, where does Rails store the current schema version number?
Think about how Rails tracks which migrations have been applied.
Rails uses a special table called schema_migrations in the database to record the version numbers of applied migrations. This helps Rails know which migrations are pending.
In a team project, why is it important not to edit existing migration files after they have been run in production?
Consider what happens if different environments have different migration histories.
Once migrations are run in production, changing them can cause mismatches in schema versions across environments. This breaks the migration system and can cause runtime errors or data loss.