I'm about installing surveyor gem, i followed the instructions there but when i executed
this line to install the gem components:
script/rails generate surveyor:install
I got these conflicts
conflict db/migrate/20120716110951_create_questions.rb
Overwrite /home/saka/modares/db/migrate/20120716110951_create_questions.rb? (enter "h" for help) [Ynaqdh] h
I know that the problem is these conflict model names in the gem and in the existing application as i already have a model named Question.
How to resolve this conflict?
This behavior is a result of an design decision in surveyor. We would like to allow people to run rails generate surveyor:install every time they upgrade surveyor, and get new migrations and changed files. The generator finds migrations with the same class name, preserves the timestamp, and presents the conflict to the user if it is different. One thing that may affect your decision moving forward is that if you do maintain your existing create_questions migration, you'll have to contend with this conflict every time you upgrade surveyor. There are a few solutions:
Surveyor could be changed to support name-spaced, configurable, or otherwise modifiable model names. This will most certainly take time, and there are currently no issues for this feature (but feel free to add one).
You could rename your migration and the generator will run. Remove the create_questions and add_correct_answer_id_to_questions migrations, and remove questions from the add_api_ids migration. Make sure your question model matches the surveyor question model as documented in the wiki (there's no guarantee we'll keep the diagram in sync). More definitively, you may create a blank rails project, add surveyor, run the generator and migrations, and then look at db/schema.rb. You'll have to keep your question model in sync with surveyor's manually.
You could rename your model. If it has existing functionality besides surveyor's, you'll probably want to go this route anyway.
How about renaming your Question Model? You Basically have to create a migration for renaming (or change the initial migration if you don't need the migration if you don't have production data yet) and find all occurrences of Question/question in your app and rename them accordingly. It's a bit of work but not a real problem.
Related
How would one manage if there were a lot of migrations file made using rails g migration?
For example if I had a file that generate a column for a certain table, I had this but again later down the track I wanted to remove this. This type of adding and removing has been repeated quite a bit due to architectural decisions along the way.
I don't like the way I'm creating migrations file for every instance of column (columns) adds and I would like to clean up all my migrations file so they are simple enough.
I understand Migrations are recorded with timestamp with matching file name and in the table to check if they have been already migrated or not. I presume I can delete that specific row in question and also delete the same thing that matches with the file after deleting the column not required.
Is this the best way to go or are there any better examples of this?
It is possible to get rid of migrations to reduce the complexity and ensure that things don't get 'out of sync'.
The simplest way is to generate a new, blank migration file. Copy across the contents of schema.rband then delete all the earlier migrations.
Obviously you would want to ensure that you are using version control (such as Git) and that your database has a backup so you can revert any problems.
I wrote a blog post on the subject here http://www.fmhcc.com.au/ruby/database-migrations-in-rails-and-when-to-start-from-scratch/
I am learning rails, and I came across Migrations. It seems that everytime I want to edit a model, I would need to add a migration script, even though I am not yet in production.
Can you edit your model, add all your attributes you need to it, and before releasing it, have the migration script autogenerated?
Thanks!
If your using rails 3+ you might want to consider DataMapper instead of ActiveRecord. It lets you define the data model in the model instead of multiple migration files. As I understand DataMapper lets you generate migrations from changes.
This is a tried and trusted pattern often used in the wider ORM community.
I agree with the comments so far. The idea of migrations is to make it simple to fluidly adapt your data schema to fit your application as you want to add new fields. It's a simple and beautiful system.
So yes, you can (and should) use rails generate migration... as not only does this generate the proper code in many common cases, it also keeps track of which migrations have been run in different versions of the database. See http://guides.rubyonrails.org/migrations.html#creating-a-migration
A common workflow might be something like this:
create a new model, for example User with fields like first_name, last_name, user_name
this will create an associated migration, which you can run using bundle exec rake db:migrate -- your database schema will be updated
you decide you want additional information, such as birthdate, so run rails generate migration AddBirthdateToUser birthdate:date. For some simple operations like adding a column, index, etc., the full migration code will be generated; in other cases you'll need to write the migration. When done, run the migration.
If you find a problem in development, for example a field type should be float, not integer, or you forgot to add an index, you can roll back the migration (bundle exec rake db:rollback), fix the migration and re-run it.
run your tests (which will run the migrations), and when it all works for you locally, check in the files (including the migrations) and deploy to a QA or staging server, which has its own copy of the database.
run rake db:migrate on the staging server. If you're on a team and other developers have checked in migrations, their will run, too. Now your code and data schema are in sync.
repeat :-)
There's no harm whatsoever running migrations during a production deployment (I respectfully disagree with a comment above) -- you should embrace the idea that change, even changes like this (which can be incredibly difficult in other environments) are a normal part of everyday Rails life!
How do you go about changing column names and types in your rails app? Do you create a new migration to make the changes, or do you rollback, edit your migration file, and then migrate again?
What's the "proper" way to do this in Rails?
It sort of depends on when this happened in your development cycle, If you recently made the change and haven't pushed it out into a public repo, then you indeed might want to do the rollback thing and then edit the migration files and migrate again, just to keep things clean. But if it's a change to a migration that's a few migrations back then you should create a new migration that changes the rows and columns to the "new" old values.
Well, to undo a migration you typically want to roll it back:
bundle exec rake db:rollback
Where VERSION= can also be specified. If you wanted to change it to something entirely new, you would make a new migration. Typically you shouldn't be touching old migrations at all.
Rails gives you the choice of creating a migration and changing it a various of ways. So there is no "ruby developers" technique of choice.
However, every time you create a migration, a file is created, and it represents the history of your development. There are a lot of cases that a simpler file should be uselfull, like a code that other ruby beginners would have to look at and modify. On other cases may be necessary to an advanced developer understand changes and improvements made on the code, specially if it is a code running for a long time (some years maybe).
I'm using NetBeans + Rails 2.3.8.
I notice that whenever I generate a model, the migration filename for it includes the date and time:
Model Name: User
Migration File Name : 20100916172053_create_users.rb
But when I see books (like Agile Web Development with Rails), the (rake-generated examples int it) all show simple numbers like 001_create_users, 002_create_sessions etc.
How do I get that simple numbering scheme (it looks neater, easier on the eyes when searching for a model)?
Or is it better to just go with the flow and not bother about what kind of versioning number is used?
You can add this to config/environment.rb
config.active_record.timestamped_migrations = false
Note that the default was changed to timestamps because it (the numbering version) causes problems in multi-developer environments. When two developers both create a migration between source control updates, the migrations will have the same numbers. If you are working alone that would not be a problem.
Also, I'm not sure how it will work if you already have existing migrations, so be careful if that is the case.
The migrations wth the timestamp are the newer form as that allows more than one person at a time to add a migration to the project. This is particularily useful in projects with more than one developer as with the old numbered approach you would need to add the migrations in lock step or renumber them.
So I would recommend that you stick with the timestamp form.
However if you still want to use the older numbered forms you can do as #ngoozeff suggested and add:
config.active_record.timestamped_migrations = false
to either your environment.rb or an initializer.
Whenever I use script/generate to generate a new scaffold for a change to my Rails database, the new migration file is prepended by a datestamp (e.g. 200903140912_create_users.rb) instead of a sequence number (e.g. 004_create_users.rb).
I then have to manually change the file name to fit in with the rest of the migration files.
Does anyone know how to fix this?
System: Mac OS X Leopard 10.5.6
Rails: v2.2.2
Ruby: v1.8.6
This was introduced in Rails 2.1. According to the migrations docs, you can revert it by setting config.active_record.timestamped_migrations to false in config/environment.rb.
I'm not sure why they made the decision, but I can tell you how it's made my life easier. On a team it was common for two people to create migrations at roughly the same time. If the last production migration was 007 then both of the new ones would be 008. The second person to commit would have a headache on their hands trying to sort it out, and the timestamps make that conflict a lot less likely.
The decision was made because when people worked together on the same project they would often try to create a migration with their new changes. This would lead to the issue where two people were working on the same project making separate changes but both generating a migration with the same number. The Rails core team decided to change it to a UTC timestamp since it's way less likely (but still possible!) that two (or more) developers would be creating a migration in the same second, rather than the same sequence.
It is also worth mentioning that using the UTC timestamp helps with sequence that migrations are run when the developers might be in separate time zones.