I generated a new migration using command,
rails g migration add_stdf_to_sds blahblah:string
I have not used rake:db migrate till now and I don't want to use it because I don't want this migration to happen, how can I delete my generated migration?
I know about rollback, but I haven't used db:migrate till now so it won't work. (I guess).
rails d migration add_stdf_to_sds
In general 'rails d' which stands for 'rails destroy' is a great way to undo any command that a generator has performed.
rails g migration adds a file in db/migrations that starts with a timestamp. Delete that file from the filesystem.
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.
So I've been going through a lot of rails tutorial, and I get that the default for adding a new column to a database is , for example,
rails generate migration add_reset_to_users reset_digest:string reset_sent_at:datetime
The above will add a reset_digest in the form of a string and reset_sent_at in the form of a date to the migration add_reset_to_users
My questions is what if I am clumsy one night at 4 AM and only call the following
rails generate migration add_reset_to_users reset_digest:string
I completely forgot about reset_sent_at but want to implement it the next morning. I made the mistake of adding the link directly to the db file, which was a huge mistake.
In this case what should I do? Do I simply call a new migration such as
rails generate migration add_reset_sent_to_users reset_sent_at:datetime
or is there an even better way?
first, if you have not run your migration, you can directly open the migration file, and add your column to the file, as
def change
add columns :table_name :column_name :column_type
end
In your case, you will modify the file as,
def change
add columns :users :reset_digest :string
add columns :users :reset_sent_at :datetime
end
and then run
rake db:migrate
if you have already ran your migration, and you have not run any other migration after that, you can undo it, by
rake db:rollback STEP=1
and then edit the migration file, and run your migration
Rule of thumb for migrations in Rails is that you always create a new migration file unless you have not already shared your code with others, i.e. pushed to remote repository, otherwise you can just change the old migration after running $ rake db:rollback and everything will be fine, and nobody will know about it, and won't affect other developers work(since it's still on your local repository).
So, I'd encourage you to create a new migration if you have already committed and pushed the code onto remote repository, and changing the old migration file again will hurt other developers productivity. In case of any confusion, always create a new migration:
rails generate migration add_reset_sent_to_users reset_sent_at:datetime
I think it depends what state your rails app is in.
If you were working on a production app then editing migrations is not advisable due to data loss and changes should be made with a new migration.
If your working locally in development then I would edit the migration directly and add the missing column and rerun your migration.
Don't be worried about editing you migrations, just remember to rake db:rollback the migration you are editing before making changes or you will encounter errors.
This is where changing your migration from:
def change
add_column('users', 'reset_digest', :string)
add_column('users', 'reset_sent_at', :datetime) # Would have to perform rollback before adding this line
end
to:
def up
add_column('users', 'reset_digest', :string)
add_column('users', 'reset_sent_at', :datetime) # Added after migration
**rake db:migrate
end
def down
remove_column('users', 'reset_digest', :string)
remove_column('users', 'reset_sent_at', :datetime) # Add this after rollback
**rake db:rollback
end
Allows you to make changes to your migrations before you rake db:rollback
This requires a bit more code but I find it easier when I'm building a new app and things are changing frequently.
I'm getting this error message when I run the above code generator: (I'm just a beginner)
invoke active_record
Another migration is already named create_posts.....
Use --force to remove the old migration file
What do I type into the terminal window to "use force"
You are getting the following error because you already have a migration named create_posts in your rails application.
invoke active_record Another migration is already named create_posts..... Use --force to remove the old migration file
So, what you need here is first remove the existing migration and then generate the scaffold.
rails d migration create_posts
rails generate scaffold post title:string body:text
Or
You could generate the scaffold using --force option
rails generate scaffold post title:string body:text --force
EDIT
As per your comment:
I did that and then a whole bunch of code appears with the lines of
code sating invoke...exist...identical.
It means that you already ran a scaffold once for Post successfully and you are trying to generate the scaffold again.
I am not sure why you are doing that BUT identical is not an error. Its just that Rails is telling you that you already have a particular file so I am not creating again.
You can reset your database if you don't care about losing your database with this :
b rake db:reset
This will re-reun all your migrations. But take note! Your migrations should be able to run from one end to the other. So if something is "not working" with the regular rake db:migrate, then you should resolve that issue is specifically.
Show me a more descriptive error, and I can tell you more.
You should add other migration in order to change your Post table as you want it to be.
Your could begin with rails g migration and see the help provided.
If you want to get away with it you can delete the migration that created the Post table (but I guess you would need to delete the DB)
After the first time you generate a scaffold, by default Rails will not overwrite the existing scaffold. This is to ensure that you don't accidentally destroy a lot of work.
If you're really sure you want to regenerate the scaffold and delete any changes you might have made to any of the generated files, try:
rails generate scaffold post title:string body:text --force
I originally had a migration called CreateUsers that had a table already.
Due to my stupidity, i thought i had to do a rails generate migration in order to add indexes to the table. When i did a migration it was this:
rails generate migration CreateUsers years:integer
So it creates a migration with the timestamp and so on, and i tried deleting using this
rails d migration migration_filename
Its giving me some error regarding this
/Users/giowong/.rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.0.2/lib/rails/generators/active_record/migration/migration_generator.rb:57:in `validate_file_name!': Illegal name for migration file: 20140219230444_create_create_users.rb (ActiveRecord::IllegalMigrationNameError)
In the schema.rb table stll exists
should i manually delete both?
You don't want to run rails d against the filename, but against the migration name you had in your generate.
Try: rails d migration CreateUsers
In order to drop the table, you'll want to rollback your migration as well:
rake db:rollback STEP=1
STEP=1 assumes this was the last migration run. You also may need to prepend bundle exec if you're using bundler in your app.
I had used default generator to create some tables and they all had that t.timestamp in their definition so the schema that was created also has created_at and updated_at fields.
Now I am told that I don't need those two fields in my schema so I went to the original create_table* files and took out t.timestamp line from them and ran the db:migrate and schema:load commands
But still when I go to my schema.rb file I can see they are still there.
Is there anything wrong I am doing here?
Run
rails g migration remove_timestamps_from_table created_at updated_at
with table being your model's name. Since this is following the pattern remove x from y, rails is smart enough to generate the appropriate migration for you.
Then run
rake db:migrate
to update your development database and
rake db:test:prepare
to prepare the test database, and you're all set!
Read more on migrations here. If you are still having trouble, consider restarting your rails server or database server.