I was attempting to add a tagging model to my rails blog. But I accidentally generated a "Tags.rb" model as opposed to "Tag.rb", after reading the guide I realized that making "tag" plural was a mistake when it comes to model. I rolled back the migration using
rake db:rollback
and then
rails destroy model Tags.rb
and this was what i got back
invoke active_record
remove /home/migration/templates/create_table_migration.rb
remove app/models/tags.rb.rb
invoke test_unit
remove test/models/tags.rb_test.rb
remove test/fixtures/tags.rbs.yml
When I come back to the model folder though its still there.
Please help :)
Just give
rails destroy model Tag
Try using tags plural without the additional .rb, like
rails destroy model Tags
Hope this helps
You can manually delete the files, or just manually remove the "s"s.
try this
bundle exec rake db:rollback
and then delete your model as
rails destroy model <model_name>
now totaly deleted.
You can delete the migration files in migrate folder and model in your model folder and then you can again create new one which you wants.
you have to run that commands
rails g model tag
Then migrate database
rake db:migrate
First off, when generating a Rails model using rails generate model, don't add .rb to the end of the model name. Rails automatically does that so if you add .rb yourself then you end up with a model named Tag.rb.rb, which is invalid.
You're running the remove generator with "Tags.rb". Did you generate the model originally using rails generate model Tags.rb? If you did, then running rails destroy model Tags.rb will hopefully remove all the files, but since the model name is invalid, it might not work as expected (your use case is outside the intended use case of the generator). If you originally generated the model using rails generate model Tags, then running rails destroy model Tags should work.
If you originally invoked rails generate model Tags.rb, and running the remove command isn't working (which again, in understandable given that Tags.rb is an invalid name--would have been nice if the generator had originally prohibited you from generating a Tags.rb.rb file, but you can't have everything):
If you can afford to destroy your database and rerun all the migrations, the easy solution will be to manually remove the added files, destroy the database, and rerun all migrations. Then you can add the correct model using rails generate model Tag.
If you can't afford to destroy your database, then you'll need to manually find the problem migration in the migration's folder, run the down command on that migration, and then manually delete that migration file and all the other files.
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'm trying to generate a Post model in rails using the following code:
rails g model Post url:string, title: string
When I execute that line I get the following output:
invoke active_record
Another migration is already named create_posts: /Users/myname/Desktop/folder/my_project/db/migrate/20121212021831_create_posts.rb
It seems to be expressing a conflict as though the file already exists in my Model folder - which it does not.
Is this a naming problem? Any thoughts?
The conflicting migration would be in your db/migrate folder, not app/models.
Your two options are naming your new migration something else or removing the old migration. If you choose to remove the old migration, make sure to roll it back first before deleting it, so that your database schema is correct.
This problem can happen when you execute rails g model post for multiple times. You can resolve this issue by executing the rails destroy model post to remove last generated content.
I am new to Ruby on Rails . This might be a very foolish question.
I have created a migration using
rails generate migration Kapol name:string position:integer
rake db:migrate
Then using phpmyadmin i copied the database already present
I then opened up rails console
My question is can i use the method Kapol.find(1)??
because when i tried it using singular or plural it says
unitialized constant:Kapol
I know that there has to be a method but where to specify it?
You must generate a model in case to create a table for it, because the migration is usually used to modify existing tables.
It might be confusing that the model generator also creates migration file in your migrations folder. The only difference is that the model generator also generates initial code to create table, on the other hand, the migration generator creates only migration file without initial code.
rails generate model Kapol name:string position:integer
More information: http://guides.rubyonrails.org/getting_started.html#generating-a-model
If you're very new to Ruby on Rails, probably the best thing for you to do is create a scaffold, which gives you your migration file, your model file, your controller file, and various view files, test files, etc. etc., which all work well together. Then you can play with these and build up from there.
rails generate scaffold Kapol name:string position:integer
If you're happy with the migration that was automatically generated, then rake db:migrate and you're all set.
As Andrew says below, you can also just generate any of those files one at a time by replacing 'scaffold' with 'model', etc.
Your Kapol.find(1) is correct.
I created a Rails model (and controller) with a typo in the name. I renamed all of the files to the correct names, and then I rolled back the migration I used to create the table and changed it to recreate the table with the proper name.
Unfortunately, ActiveRecord still wants to use the old table name, even though it does not appear in any file in my project. I assume it has been cached somewhere but I have no idea where. There are no files in the application's tmp directory that look suspicious.
For the time being, I added a call to "set_table_name" to the model to get around the problem, but I'm really curious about where the old table name is stored and how to get rid of it.
Update: I went ahead and deleted the scaffold using "rails destroy scaffold". When I recreated it (without the typo), it recreated everything with the typo! I know the typo is cached somewhere but I have no idea where.
Rafe - Looks like it could be a bug in Rails. Perhaps you could submit a Rails pull request, or try adding to the config/initializers/inflections.rb file.
have you fixed the class name of your model? rails infers the table name from that
e.g. "class Userr" -> "userrs"
I generally spot typos quite quickly: the first time that the model is mentioned in the console or associations; the controller in the routes.
When I rails generate model urser I just rails destroy model urser and start again.
This just blasts the files away, but it's very convenient and in rails 3 works especially well to destroy every file created by the generator.
If I migrated before spotting the typo I'll let the migration be deleted by the destroy script, let the generate write a new one and then rake db:rollback. That way the urser_table from the previous migration is dropped and the user_table is created.
If there's a bit of code in the files, at that point is mostly in the model or controller itself. I just copy to clipboard the meat of the class before deleting the file and I paste it in the next one.
If there's a lot of code inside various models tests, controllers or helper files: I still use the same approach, but commit it to git before running destroy, so if you something it can always be checked back out.
OK, it turns out that with Rails 3 (and maybe other versions) if you try to generate a model named "Cafe" it will use the name "cave" instead. No idea why.
Here's an example. I duplicated this on different computers, too.
holloway:whatever rafeco$ rails g scaffold Cafe
invoke active_record
create db/migrate/20110412190231_create_caves.rb
create app/models/cafe.rb
invoke test_unit
create test/unit/cafe_test.rb
create test/fixtures/caves.yml
route resources :caves
invoke scaffold_controller
create app/controllers/caves_controller.rb
invoke erb
create app/views/caves
create app/views/caves/index.html.erb
create app/views/caves/edit.html.erb
create app/views/caves/show.html.erb
create app/views/caves/new.html.erb
create app/views/caves/_form.html.erb
invoke test_unit
create test/functional/caves_controller_test.rb
invoke helper
create app/helpers/caves_helper.rb
invoke test_unit
create test/unit/helpers/caves_helper_test.rb
invoke stylesheets
create public/stylesheets/scaffold.css
I have a bunch of rails models that I'm re-writing into a single model to simplify my code and reduce unnecessary tables.
I'm wondering what the best way to delete a model class and its table is. I want past migrations to still succeed, but I don't want to leave the empty models lying around.
Do I have to manually delete the old migrations that reference these models, then manually delete the class files?
Does anyone have any tips for the best way to do this?
All in one solution.
Run the following commands:
rails destroy model ModelName
rails g migration DropTableModelName
The former will generate a new migration file which should looks like this:
class DropTableModelName < ActiveRecord::Migration
def change
drop_table :model_name
end
end
Now run db:migrate and you're done.
If you'd like to completely get rid of of a model and its table do this:
rails destroy model Name
The question is a bit stale now, but I just did:
rails destroy scaffold <ModelName> -p
The -p flag shows "pretend" output, which is good for seeing what will happen. Remove the '-p' flag and the results will match the output. This cleaned the entire collection of M-V-C files + testing + js files + the original migration, no problem.
I guess if you are one who likes to hand edit your migrations and include multiple steps in each, losing the original migration could break db:setup, so buyer beware. Keeping one action == one migration file should avoid this potential snafu.
What about doing ruby script/destroy model? That should take care of the model and the migration.
Depending on how far into development or production you are, you may want to migrate the models out safely using a migration to remove/backup data or what not. Then as bobbywilson0 suggested, using
script/destroy model
or if you rspec anything
script/destroy rspec_model
This will remove any spec tests as well.
Or you can always just drag them to the trash folder.
You can take a look at this one at rails guide.
But I suggest, if it is possible, you should delete the models and all references to the models. This will probably save time later as you don't need to maintain the dead code in the codebase.
If you'd rather have a manual based answer:
First run the following command to identify which migrations you want removed:
rake db:migrate:status
Feel free to grep -i on it too if you're confident of your naming scheme.
Make note of all the "add x to model name" and similar alterations to your Model. These can be removed using:
rails d migration AddXToModelName
Do this for every migration besides the initial create migration. The following command will take care of the initial create migration and the files associated with the model:
rails d model ModelName