What is the best possible way to change name of table using migration and change name of all the files like controller, model and associations?
Will there be any issue when someone will try to run rails:db:migrate after cloning my repo?
What is the best possible way to change name of table using migration
To change the name of a table, you can run:
$ rails g migration change_[old_table_name]_to_[new_table_name]
Within the change method in the migration file generated, add this:
def change
rename_table :[old_table_name], :[new_table_name]
end
Change [old_table_name] and [new_table_name] in both cases.
(This part of the question has been answered here.)
will there be any issue when someone will try to run rails db:migrate after cloning my repo?
Nope. Keep the old migration files in place and generate a new one. That's the benefit of database migrations.
What is the best possible way to change name of all the files like controller, model and associations?
It's generally not too big of a deal to change a model name. Many text editors have the ability to search and replace within a directory.
And I would manually rename the filenames.
Here's a set of more detailed steps to make sure you've hit everything that needs to be changed.
Related
Is it possible to specify a different table name (other than versions) for the PaperTrail gem?
In my Rails app, I already have a Versions model/table, which has nothing to do with active record versioning (my app let's uses fork a "prototype" and for better or worse I used "version" as a label for these forks). It is quite pervasive through my app, and I don't want to rename this.
When running bundle exec rails generate paper_trail:install, I get Migration already exists: create_versions.
Basically, I would like the table to be PaperTrailVersions along with the methods to access the trail to be similarly namespaced.
Any ideas? Or should I just use the Audited gem which uses a audits table?
PaperTrail supports custom version classes which can have custom table names defined.
class PostVersion < PaperTrail::Version
self.table_name = :post_versions
end
class Post < ActiveRecord::Base
has_paper_trail :class_name => 'PostVersion'
end
As of the failed generate command, I would try these steps (haven't tested them though):
You already have a migration with the name CreateVersions because you already have a versions table. That is why the generate command fails - it cannot create a migration with the same name. I think that you can simply temporarily rename the old migration (for your original versions table migration). You just need to rename the file and the classname inside the file.
Then the generate command should run. It should install a few files, their names will be printed out to the console.
Now open the newly generated create_versions migration file and rename it as well as the class name inside from CreateVersions to a name according to your custom versions table name, such as CreatePostVersions. Also rename any mention of the versions table inside it to your custom table name, e.g. post_versions.
Open all other generated migrations and change the versions table names to your custom table names inside them. There is no need to rename these files though.
Now go back to your original (and now temporarily renamed) create_versions migration file and rename it back to its original name (revert the changes on this file).
Try to run the migrations! It should work now.
The steps may seem cumbersome but they just temporarily rename the old migration to something else so that the generation command can run. Then you just need to change the table name inside the generated migration to the new table name.
The files that will be generated with the generate command can be seen here in the source code. These are the files that you'll need to modify.
I used
rails generate model Suject
when I should have spelt it
Subject
Is there a quicker way to correct this than delete all the files?
You can not rename this as it already created migration also for this. If you want to do this you need to manually change each file created by command and it's name also.
But you can simply destroy and generate new.
rails destroy model Suject
and then
rails generate model Subject
No, but if you are using git (which you should), why not just run:
git reset --hard
rails g model Subject
?
I have created a class using scaffold in rubymine and did db migrate. Now I need to add one more instance variable (one more column to table in db) to the same class. How do I do this using rubymine (not from command-line) without destroying the class?
I don't think I understand the real issue here.
Would you not just rollback the current migration modify the migration in db/migrate (N) and add the column you want, then update the views for the model (since you've used a scaffold)? Once you do that, you would migrate again. Either that, or you'd create a new migration that adds the column you want– however, given that you've obviously just started this app, I see no reason to add an additional migration simply for this.
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
I'm new to RoR, and I've just used scaffold to generate a table and create the pages for CRUD operations. Now I want to add a new field to this. One place I found tells me how to do that in the database, but is there a way to do it where it will add the field to all the pages too, or is that just a manual operation and I need to make sure I know all my fields up front?
To add a new column to the database
$ script/generate migration add_fieldname_to_tablename fieldname:string
$ rake db:migrate
To get your views up to date you can run the scaffold again, with your updated list of fields. It will balk on replacing your migrations but you can force it to replace your views.
$ script/generate scaffold tablename fieldname:string old_field_1:string ...
At the prompt answer a and it will overwrite the views, but not the old migration. It also won't modify your existing data.
First you'll write a migration to add the field, run the migration, then you need to rerun the scaffold to regenerate the views, etc. Beware, this will wipe out edited files from before. Of course, instead of scaffolding again you could manually add references to new field where appropriate.
You will have to update your database, no matter what (Remember to 'rake db:migrate' after you create the migration!)
Regarding the interface, you are a bit more lucky: the formtastic plugin makes your views look like this:
The 'f.inputs' is calculating the form fields on-the-fly, based on your model's attributes. This will not cover complex forms that need special treatment, but the usual ones, you will get them automatically.
For an easy-to-understand tutorial, see the latest railcast (Railscast #184, you will have to google for it, I can't post 2 links because I'm not cool enough for stackoverflow yet, sorry).
Railcast #185 is supposed to continue covering formtastic, and it's due to be published next monday.
Needs to be done manually, or the scaffold needs to be regenerated.