What is happening under the hood when executing this?
rails generate migration create_menu_categories_and_menu_items
Why can't I just create a file in the migrations directory? It seems I have to use the generate command in order for it to actually run, but the only file I see changed is the file created by the above command.
You can, but you need to get the time stamp at the beginning of the file name, so that rails can figure out that it's a "pending migration" and run it. It does this by storing the time stamp (or version in migration parlance) in a special database table (schema_migrations) and anything newer than the last run migration is pending.
Otherwise there's nothing special about the file itself
You dont even have to create a separate migration file. You can just add a column to your table by adding the object to to your current migration class like this:
t.string :name
Then run a rake db:migrate
Hope this helps.
Related
I created a rails migration with
rails g migration CreateThisWeekView
I then realised it has the wrong name. As I have not done a 'db:migrate' can I just delete it and re-create the one with the correct name?
Yes, rails generate creates files, it doesn't do anything else. rails generate migration just creates a migration file, it doesn't change the database, so you can just delete the file.
You can delete the file manually or by using rails destroy:
rails d migration CreateThisWeekView
destroy is the command to undo code generated with generate.
Yes, you can, try with the opposite to create a migration, that's destroying it, like:
$ rails d migration CreateThisWeekView
Without having modified the structure of your schema you don't need to make a rollback. I guess just destroying the created files you can achieve what you want.
I have different migrations file
20120205111326_change_users_login_limit.rb
20120223110929_change_attachments_container_defaults.rb
20120223110300_change_locals_container_defaults.rb
20120223110301_change_position_tracs.rb
I want to run up migration of 20120205111326, 20120223110929, 20120223110300 just before the last migration but condition is that it should not point its migration VERSION numbers...
Is there any ways to do it...please suggest me..
Thank you in advance
There is one way, Run your migration via rails console
require "db/migrate/20120205111326_change_users_login_limit.rb"
ChangeUsersLoginLimit.change # or 'up' or 'down' whatever method of that migration you want to run.
And do the same for all migration (don't forget to do it in sequence)
EDIT:
Rails actually don't provide a way to run migration skipping some. or run them by changing order. But the migration files are actually a ruby programs containing a single class. So you can always create a rake task and require migration in to rake task and run them in the custom logical order. After all migrations are the classes with methods.
I am a little confused how migrations affect schema.rb file?
For example if I write a migration to rename a table column and run that migratin and even do a schema:load rake task too, then when I open my schema.rb file should it automatically be changed to have that new column name? or should I manually change it in there too?
Also my create_table*.rb files that create the original tables. They automatically have a t.timestamp field defined in them that creates those two created_at and updated_at fields in the schema, so if I want to remove those is it enough to just alter the create_table*.rb file and take out t.timestamp from them? and run the migration? or again I should manually alter shcema.rb file too?
So if someone can explain a little bit how there work together would be great.
The schema file is automatically altered when you run migrations. You should never have to manually edit it.
See this Rails Guide for moer information.
If I have two migration files:
20110414132423_insert_bulk_data.rb #1st
20111122105951_add_some_columns.rb #2nd
and I run rake db:migrate, is the 1st one run firstly since it has older timestamp??
Since I am in the middle of someone else's code, he made the 20110414132423_insert_bulk_data migration which insert data to table, but this migration file complains an unknown column in the table, then I found the missing column is defined in the 2nd 20111122105951_add_some_columns.rb migration file which has newer timestamp...
How can I get rid of this?
Shortly, yes. The timestamp is used to order migrations and to navigate between them. See more here
delete this migrations
generate two new migrations in the way you need to run
If I edit my shema, and run db:migrate the database doesn't changed, but if I clear to version 0, and recall migration it's works, but I lost all database data.
What's wrong?
That's how db:migrate works. It maintains a table in the database called schema_migrations that keeps track of the migration timestamps (i.e. if your file is called 20090807152224_create_widgets.rb, the 20090807152224 part is the timestamp -- and the line that will get added to your schema_migrations table).
You're not supposed to modify the schema.rb file by hand -- that file gets autogenerated as a result of db:migrate.
The thinking in rails is that if you want to make a change to your schema, you're going to generate a new migration with those changes and then run db:migrate (which, as a result, will update the schema.rb file appropriately).
When you say you are updating your schema, does that mean you're updating the db/schema.rb file, or actual migrations?
If you're updating the schema.rb file, you should note that it will have no effect because the file is auto-generated.
See the comment at the top of the file:
# 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.
It sounds like you were changing a migration file.
Don't change migration files. Add new ones. You can have migrations that change say, the type of a column. There are times when changing old migrations may be helpful, but don't do it unless you know the consequences. As others have mentioned, don't change the schema either, but I don't think you were doing that.