Migrate to Devise in Ruby on Rails - ruby-on-rails

I have an existing model that uses bcrypt to encrypt the user password.
I wonder how I could migrate to use devise?
Do I still install devise the normal way and change the model attribute via database migration?

Add devise to your Gemfile, run bundle install, then rails generate devise ModelName (change ModelName to actual name of your model). This should add all needed things to your model as well as create a migration. I think devise will know, that your model already exists and it won't try to create new table, but it will modify existing one instead.
Then just run rake db:migrate, restart server and you should be good to go.
Just to be sure, use git or some other versioning system. It's been a while since I last tried this, so make sure you can easily go back, if something goes wrong.

Related

Ruby on rails Database setup using scaffold generator or Manually

I am new user to ruby on rails. I have some question please give the answer as early as possible
What is the Best way to Create a Database For Your Projects in Rails?
1.Scaffold generator
2.Manually Design Database​
After installing the Rails then create a project using rails new project_name then cd project_name then run rake db:create it will create a database.
You can modify database name like by default rails uses a database e.g name_development or name_production you can modify this on go to project/config/database.yml.
The rails new project_name command creates default database adapter e.g sqlite3 you can define this which adapter he use by default while rails project create.
The sqlite is a development database you should change database adapter while going to production like postgresql or mysql or mongodb...
If you need to use mysql by default then run below command
rails new project_name -d mysql
If you need to use postgresql by default then run below command
rails new project_name -d postgres
It will create a database adapter by default which you need.
Note: You can use both for a command like rake new project_name or rails new project_name
You need to the read the Rails Guides carefully for understand basic Rails. This tutorial assumes you have basic Rails knowledge.
Also here are the Rails Commands
Ruby on rails Database setup using scaffold generator or Manually
The scaffold works after create a database.
You can see the active record basics and for basic association you can see the Michael Hartley tutorial this is good tutorial for new RoR programmer.
After all you need to design manually using reference or defining by index foreign key
First of all decide what kind of database are you going to use. (Msql2 or Postgres are mostly used)
Then design the schema on a paper or anywhere else.
And whenever you're sure. Now everything comes down to 2 different things.
You want things to be created automatically. for example: Views, CRUD for database operations in controllers.
You want to control things on your own. Now create model from rails commands, write associations, and begin writing your code and define routes as well.
NOTE: Point 2 is implemented when you're going to create a custom application and you may need operations other than basic crud.
Now, you can tell us. What actually you want to achieve and people will help you.

Rails will not let me destroy scaffolding from nifty generator

I was following one of the railscasts tutorials and decided to install nifty generators. Well, being a rails noob I didn't realize that the way parameters are handled changed. Now I can't undo any of my changes. So far I managed to roll back the database but every time I try to run
rails destroy nifty:scaffold mymodel
I get the error message
attr_accessible is extracted out of rails into a gem. Please use new recommended protection model for params(strong_parameters) or add protected_attributes to your Gemfile to use old one.
So I did. I added
gem 'protected_attributes'
and ran
bundle install
Then I tried to destroy it and it errored out again. I really hope nifty didn't just screw up my project. Can anyone help?
Um, this not a real solution, but a possible workaround: if the output of the rails generate nifty:scaffold mymodel command is still in your terminal buffer, you could manually delete the files it created.
And if the output isn't available, you could do rails generate nifty:scaffold mymodel2 in order to see what files nifty:scaffold created before manually deleting the corresponding files for mymodel.
Not elegant, but it might get you over the hump.

conflict model names in surveyor gem

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.

Rails form to database setup

I'm fairly new to Rails, and I have a few beginner's questions. I want to create a beta signup page for my web app, something like this http://www.realestapp.com/ . How do I go about initializing such a rails project - what gems should I install and what generate commands should I use? I know I need a User model, with a string attribute to save an email address. I want to save the user email address from the form into a sqlite3 database.
Thanks!
I'm a big fan of the nifty gem (https://github.com/ryanb/nifty-generators). It greatly reduces headaches. Add it to your gemfile and run bundle install. Then you can just:
rails generate nifty:scaffold User email:string

Rails - Generating migration script from model

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!

Resources