I have installed Devise and now want to remove it, including all the files it has generated. How do I do that?
I'm looking at solving the same problem today and since this is not answered, giving it a go =)
Models
Devise generates a User model if you installed by default.
Remove the lines under devise. This is how mine looks like.
devise :database_authenticatable, :registerable,
:recoverable, :rememberable, :trackable, :validatable
In attr_accessible, you may remove email, :password, password_confirmation and remember_me if you no longer need them.
Views
A default Devise install doesn't generate views in your app folder. If you generated overriding views for Devise, you may remove them by running rails destroy devise:views (Rails 3).
Generally, all the views are stored in app/views/devise.
Controllers
By default, Devise doesn't generate any controllers too. If you did any overrides, they are most likely known as registrations_controller. Search your project for controllers that inherit Devise::RegistrationsController class.
Also, if you followed Devise's wiki and monkey-ed around to add redirect methods etc, look out for methods such as after_sign_in_path_for, store_location etc that are for redirecting users.
Migrations
If you installed Devise via its generators, look out for a migration create_users. If you don't need it anymore, use drop_table :users in a migration to get rid of it.
I'll assume most people would want to keep their User model. If you're using Devise < 2.0, the migrations are done by helpers. Once you remove Devise from the Gemfile, Rails will not understand the helpers below and throw errors, for instance, when you're trying to rerun these migrations on another box. These helpers are:
t.database_authenticatable
t.recoverable
t.rememberable
t.trackable
t.encryptable
t.confirmable
t.lockable
t.token_authenticatable # => becomes t.string :authentication_token
For the exact columns, the below is reference to the columns generated by Devise.
https://github.com/plataformatec/devise/wiki/How-To:-Upgrade-to-Devise-2.0-migration-schema-style
The guide above lists the fields generated by Devise using the helpers. You should be able to look through the list and your model (e.g. calling User in console), generate a migration that removes those columns.
BUT...
It's a little unfortunate that for consistency, we have to convert the migration to not use helpers using the guide above then generate a migration to remove them. This is for migration history consistency, otherwise anyone running the migrations might try to call the non-existent helpers. Also, your migration to remove the fields will also expect the fields to be present.
Alternatively, it might be a good time to squash the migrations and rely on schema.rb / structure.sql for the schema's to-date state. Even after deleting migrations, you can always recreate your development DB anytime using rake db:schema:load.
Initializers and Locale
Remove devise.rb in config/initializers and devise.en.yml in config/locales.
Routes
Remove any devise_for lines. These will raise errors after the removal of the gem.
Gem File
Yaay. All dome, remove the line gem 'devise' from your gemfile.
Use the generator to remove configuration files as well (step 2), so the whole process would be (referencing previous answers):
Remove the table: rake db:rollback VERSION=<insert the version number of the migration>
Remove the configuration: rails destroy devise:install
Remove your User model: rails destroy devise User (replace 'User' with the name of your model)
Remove references to devise in your routes.rb, gemfile, controller files, and view files like the following, if you used them (once again replacing 'user' with your model name):
devise_for (routes.rb)
gem 'devise' (gemfile)
before_action :authenticate_user! (controllers)
user_signed_in? (controllers, views)
current_user (controllers, views)
user_session (controllers, views)
In my case I had two models User and Admin and I am sticking with Devise, but I had a name collision issue with ActiveAdmin that requires me to remove the Admin model. But because there were so many references to Admin in devise, I had to take the steps below. I think it answers the original question above as well, though. I believe the correct way to do this is:
1.Find the devise migration for the user model and roll it back [IMPORTANT: IF you DON'T want to remove the user table associated with Devise, then SKIP THIS STEP]:
rake db:rollback VERSION=<insert the version number of the migration>
example:
rake db:rollback VERSION:20110430031806
2.Run this command to remove Devise and associated files.
rails destroy devise Admin (if Admin is the name of the model with user accounts).
This produces this output:
invoke active_record
remove db/migrate/20110430031806_devise_create_admins.rb
remove app/models/admin.rb
invoke test_unit
remove test/unit/admin_test.rb
remove test/fixtures/admins.yml
route devise_for :admins
3.To completely remove Devise, you need to remove all references to it in your models, controllers and views. This is manual work. The answer above provides good details for finding this cruft, but was incomplete for my purposes. I hope this helps someone else.
I found daemonsy's reply to be very helpful. Here are a few other things to consider as you do this.
Replacing Devise
If you are going to replace Devise with your own authentication, I recommend this Railscast: Authentication from Scratch (revised) (subscription required, but it's the best $9/mo you can spend).
And this Railscast (no subscription required) can help with a forgot password link and "remember me" option (things Devise offers out of the box, but that you can build pretty easily yourself): Remember Me & Reset Password
Tests
Before you do this, I recommend running all your tests to make sure they're passing.
After you remove Devise, your authentication-dependent tests will probably fail, so plan to spend some time fixing failing tests. This is a good thing because it will help you see what stuff "broke" when you removed Devise.
Make sure you check your test helpers as well. Most of my helpers were in /spec/spec_helper.rb. In fact, most of my failing tests began passing once I updated the methods in spec_helper.rb (eg, "login_user").
This worked for me!
1: rails d devise User This deletes the model and the routes.
2: rails d devise:install , This destroys devise.rb and
devise.en.yml files.
3: create a migration eg: rails g migration drop_user_table. I
used drop_table :users , force: :cascade, force: :cascade; takes
care of
PG::DependentObjectsStillExist: ERROR:
that occurs if other tables depend on the user table.
Related
I remember one of my colleagues did this but I don't remember how. Guess he used some gem or a rake task to achieve this.
Please share if you know how to do this.
Maybe even a gem that can add relevant associations automatically to the model file. This when we do rails g model.
You can use this gem:
https://github.com/ctran/annotate_models
Then run annotate from the terminal. It notes if the field is hstore or array type in case of postgresql. So it is very intelligent. Even myself made a commit to it ;)
I have an application that was running just fine using Devise for authentication. I added CanCan and I am now having issues with Devise. Given the standard "encrypted_password" and "password_confirmation" attributes if they are not specified as attr_accessible then when the controller tries to do:
#user = User.new(params[:user])
I get the standard MassAssignment error. But if I add them to the attr_accessible list I can then create the user but it will then fail on password validation since the attr_accessible does not let Devise encrypt the password. I suspect the issue is something in my routes since I have both:
devise_for :users, :path_prefix => 'secure'
resources :users
The resources :users is there so that the admin and use standard CRUD type operations to manage CanCan.
Not sure if more detail is needed but this sounds like a core issue that I am stubbing my toe on.
Thank you
I found the problem. Someone had changed the model's attr_accessible list to have encrypted_password not password. Devise is looking for the password in the parameters and then creates the encrypted_password for the model.
Another newbeee programmer has learned a lesson :) So did I, double check changes made by newbes!
Thankyou
From the DataMapper document, I think there are at least four functions need to be called to have database setup:
DataMapper.setup(:default, 'sqlite:///path/to/project.db')
DataMapper.finalize
DataMapper.auto_migrate!
DataMapper.auto_upgrade!
In many DataMapper+Sinatra tutorials I learned that auto_migrate! and auto_upgrade! are not supposed to be called every time the app is loaded on production server. But in the meanwhile many examples call these functions in the main ruby file of the sinatra app, say app.rb, without additional check. And some examples do not call finalize at all. So far I am confused and I am not sure what to do on the production server.
Take this following simple app.rb for example, I have some questions:
Where and when should finalize be called?
When deploying the app first time there is no db file on the production server, how do I have it automatically created? Or do I have to create the project.db file manually?
Since the auto_upgrade! is wrapped in :development block, it won't be called on production server. How am I supposed to upgrade database when I add or remove columns in it?
require 'sinatra'
require 'data_mapper'
configure do
DataMapper.setup :default, "sqlite3://#{Dir.pwd}/project.db"
end
class Book
include DataMapper::Resource
property :id, Serial
property :title, Text
belongs_to :author
end
class Author
include DataMapper::Resource
property :id, Serial
property :name, Text
has n, :books
end
configure :development do
DataMapper.auto_upgrade!
end
get '/:id' do
#author = Author.get params[:id]
erb :list_author_and_his_books # The template has nothing to do with this question, ignore it
end
get '/new' do
# Some code for user to input book or author details
end
get '/create' do
# Some code to create book or author in db
end
Thanks for reading this long post :D
Where and when should finalize be called?
From http://rdoc.info/github/datamapper/dm-core/DataMapper#finalize-class_method
This method should be called after loading all models and plugins.
When deploying the app first time there is no db file on the production server, how do I have it automatically created? Or do I have to create the project.db file manually?
It depends on your hosting arrangement, but the main thing to do is put the running of migrations in a Rake task and run them when the app is deployed. If you're using Sqlite, this would create the database (although on some hosts you are not allowed to update the file system). I don't think it's a good idea to use Sqlite for a production database, but that's your decision.
Since the auto_upgrade! is wrapped in :development block, it won't be called on production server. How am I supposed to upgrade database when I add or remove columns in it?
Use a Rake task. After each deployment you'd run the "db:migrate:up" (or whatever you'd called it) task and it would run the latest migrations. You might get a few ideas from Padrino's Rake tasks for DataMapper
I am just starting my first ruby project. I followed tutorial and built a blog. I thought next i would add a commenting system to extend the project, I just added has_many :comments to my post model. In the tutorial after we built the model we raked the database. Im not entirely sure what it does, but it seems fairly important. Is this something at I will need to do again and any time i update a model? I am using the gem 'sqlite3'
thanks
Every time you create a new model (database table) you got to run the migration, which creates the table in the database. Whenever you make any change to the db, you got to run migrations so as to make sure your db is in sync with your latest changes.
Everytime, you create/edit a model(database table) in rails, you should write a migration for the same. The migration will make the necessary changes to your database once it is run using "rake db:migrate" command.
With the has_many :comments in your blog model. You will need to add a migration to create the comments table, with blog_id as the foreign key, assuming your blog model is called 'blog'.
I'm migrating a sinatra app I have that acts as a backend UI for our DNS database. I've already got the DM configs in the sinatra app but want to migrate it to padrino so I can make it cleaner and easier to read, but also because I want to play around to padrino. If I just generate a new model, can I perform the datamapper mapping in that model, including specifying the db application and get away with doing that instead of using a generator?
What do I need to do to be able to access models on a different database, ideally without damaging that data base (read only)
Right so you actually can do this I found out with a bit of trial and error. Specify the datamapper database source in the config/boot.rb there's a section labelled Padrino.after_load, you'll want to add in your new DataMapper source here
DataMapper.setup(:myalternatedatasource, "MY_ALTERNATE_DB_URL
Then in your model file you'll want to specify
def self.default_repository_name
:myalternatedatasource
end
And it'll all work as intended!