I'm trying to install activeadmin on rails with devise.
I added gemfile and ran
rake db:migrate
and i met these errors.
== 20170821153121 DeviseCreateAdminUsers: migrating ===========================
-- create_table(:admin_users)
rails aborted!
StandardError: An error has occurred, this and all later migrations canceled:
SQLite3::SQLException: table "admin_users" already exists: CREATE TABLE "admin_users" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "email" varchar DEFAULT '' NOT NULL, "encrypted_password" varchar DEFAULT '' NOT NULL, "reset_password_token" varchar, "reset_password_sent_at" datetime, "remember_created_at" datetime, "sign_in_count" integer DEFAULT 0 NOT NULL, "current_sign_in_at" datetime, "last_sign_in_at" datetime, "current_sign_in_ip" varchar, "last_sign_in_ip" varchar, "created_at" datetime NOT NULL, "updated_at" datetime NOT NULL)
/Users/admin/.rvm/gems/ruby-2.4.1/gems/sqlite3-1.3.13/lib/sqlite3/database.rb:91:in `initialize'
/Users/admin/.rvm/gems/ruby-2.4.1/gems/sqlite3-1.3.13/lib/sqlite3/database.rb:91:in `new'
/Users/admin/.rvm/gems/ruby-2.4.1/gems/sqlite3-1.3.13/lib/sqlite3/database.rb:91:in `prepare'
/Users/admin/.rvm/gems/ruby-2.4.1/gems/sqlite3-1.3.13/lib/sqlite3/database.rb:137:in `execute'
...
Well the error is fairly self explanatory, your database already has a table with the same name Devise/Active Admin wants to use and table names must be unique.
Did you already at some point already use/try the activeadmin gem? If you already created the tables for it, trying to create and execute new migrations will fail, but you should be able to either just use those, or delete them and make fresh ones.
Or does your application just happen to have a AdminUser model for its own use? If it does one of them has to change.
You should be able to see either case in your db/schema.rb, or in the old migrations in db/migrations/. If you tried deleting/reverting a migration by just deleting its migration without script without rolling back first (either rails db:rollback or a DB backup), you may also have old tables actually in the DB, which you may want to manually delete.
If you do need to rename the Active Admin tables, the advice given in Github Database tables name prefix #4960 is to manually edit the migration and use self.table_name= in the models to tell them the new names.
Well, the error it self repeat that you have already the same table called "admin_users".
Please run the command on rails console to see your already created tables like this way:
ActiveRecord::Base.connection.tables
If you would find same table in the list then you need to delete that table manually or another way is just drop your db and recreate it after that you can able to run your new migration.
Related
I'm having some DB issues with rails. When I run rails db:migrate I get the following error:
add_column(:locations, :user_id, :integer)
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:
SQLite3::SQLException: no such table: locations: ALTER TABLE "locations" ADD "user_id" integer
The problem seems to be that I have a migration that is trying to add :user_id to a table :locations but this table does not exist because I deleted it and it is therefore not in the schema. How do I solve this? I always thought it was a bad idea to delete migrations.
It depends. Was locations created and deleted by migrations? If so, is the failing migration, in time terms, between those migrations?. If the answer is yes then you should not delete it.
In the other hand, if you deleted locations by hand or by migration before the failing migration then remove it, since it makes no sense to your schema.
I'm attempting to add password verification to my application. I've been following the directions on the Devise Wiki but when I attempt the migration I get the following error:
== 20150127183211 AddConfirmableToDevise: migrating ===========================
-- add_column(:users, :confirmation_token, :string)
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:
PG::DuplicateColumn: ERROR: column "confirmation_token" of relation "users" already exists
: ALTER TABLE "users" ADD "confirmation_token" character varying/Users/esteban/Code/rails/ComicBookDB/db/migrate/20150127183211_add_confirmable_to_devise.rb:4:in `up'
ActiveRecord::StatementInvalid: PG::DuplicateColumn: ERROR: column "confirmation_token" of relation "users" already exists
: ALTER TABLE "users" ADD "confirmation_token" character varying
/Users/esteban/Code/rails/ComicBookDB/db/migrate/20150127183211_add_confirmable_to_devise.rb:4:in `up'
PG::DuplicateColumn: ERROR: column "confirmation_token" of relation "users" already exists
/Users/esteban/Code/rails/ComicBookDB/db/migrate/20150127183211_add_confirmable_to_devise.rb:4:in `up'
Tasks: TOP => db:migrate
(See full trace by running task with --trace)
However, I do not see confirmation_token reflected in schema.rb. Perhaps I should reset my database? If so, what is the easiest way to do so? Any help would be appreciated.
It depends on how you installed your current database.
If you made it with rake db:create/rake db:migrate - there should be a migration with corresponding fields(maybe removed/modified, they can not magically appear).
If you setup your db using someones dump - it explains how fields appeared in db, but not in schema.
If you are in development mode and have no valuable information in database, easiest way is to re-create your db from scratch:
rake db:drop:all
rake db:create:all
rake db:migrate
If you have valuable information or your migrations don't fully represent current state of db(maybe you removed some of the migrations or use dumps in team to share information), just skip the step with fields creation in instructions since you already have them.
I'm fresh on RoR. I get really confused when I updated my database. I added some tables in my database, and then I want to update schema.rb, so I use rake db:schema:dump. Everything goes fine. Immediately after the previous command, I use rake db:schema:load, but there is an error:
Mysql2::Error: Incorrect column specifier for column 'partition': CREATE TABLE `ab_test_result` (`id` int(11) DEFAULT NULL auto_increment PRIMARY KEY, `model_id` int(11), `group_id` int(11), `kpi` varchar(255), `related_info` varchar(255), `category` varchar(255), `task_group_run_id` int(11), `timestamp` datetime, `partition` float(64), `actual_partition` float(64)) ENGINE=InnoDB
How does this happen? What should I do? Thanks.
schema.rb is handled by the migrations. You don't need to dump - load each time.
Generate a migration:
rails generate migration foo_bar
you write your migration's code and then
rake db:migrate
schema.rb is updated if the migration succeeds
I am getting an error when I try to migrate my db. I don't entirely remember how I got here, but I believe I:
created new branch, scaffolded 'Requests', db:migrated, switched back to master, and merged branch
created another branch, did some stuff, db:migrated, and everything was working fine.
pulled from heroku postgres database so i could test out if things worked with actual data. then tried db migrating, but gave me this error:
rake db:migrate
== CreateRequests: migrating =================================================
-- create_table(:requests)
NOTICE: CREATE TABLE will create implicit sequence "requests_id_seq1" for serial column "requests.id"
rake aborted!
An error has occurred, this and all later migrations canceled:
PG::Error: ERROR: relation "requests" already exists
: CREATE TABLE "requests" ("id" serial primary key, "title" character varying(255), "content" text, "category" character varying(255), "status" character varying(255), "requested_track_id" integer, "created_at" timestamp, "updated_at" timestamp)
Any ideas?
I'm not sure exactly what pull strategy you used, but if we make two reasonable assumptions about your pull strategy:
it doesn't drop the database but just overwrites tables, since this requires less permissions.
it is operating in a sort of 'archive mode', meaning it doesn't drop tables on the destination just because they don't exist on the source. Think rsync; you have to specify --delete to get what might be your expected behavior with that utility.
If your steps are correct, then what happened is you overwrote the schema_migrations table, so Rails thinks you haven't added the table yet, but neither did your heroku pull drop the table because of #2 above.
Don't create another migration!!! This will fail on everyone elses' computer except yours, but will only run on yours once.
Instead, run rails dbconsole and execute something like DROP TABLE 'requests' (I forget the postgres syntax, might not be exactly that). Then you can run your migrations.
There is another way to avoid dropping a table with data in it.
What I do in those cases is to check which migration is failing.
Suppose you have a file db/migrate/20130908214222_create_requests.rb, and for some reason, ActiveRecord failed in the past when stored this migration in its "tracking system".
To be sure that this is the case, just find, in the schema_migrations table, a row containing a number like this example: 20130908214222
If that row does not exist, you just have to insert a new one:
INSERT INTO schema_migrations(
version
) VALUES (
20130908214222
);
Next time you run rake db:migrate, ActiveRecord will omit this step, and will continue migrating to end without complications.
I'm following the RailsTutorial.org tutorial, section 7.3 and trying to do a db migration using rake to add a password column to an existing database. What appears to be happening is that rails is re-running a previous migration file and trying to add table Users (which exists already) rather than the most recent migration file and add a password column. Any help would be appreciated!
Here is the code I ran to generate the migration file:
$ rails generate migration add_password_to_users encrypted_password:string
Then I ran rake db:migrate and got the following error:
An error has occurred, this and all later migrations canceled:
SQLite3::SQLException: table "users" already exists: CREATE TABLE "users" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "name" varchar(255), "email" varchar(255), "created_at" datetime, "updated_at" datetime)
Rails will run any migration whose number is not in the schema_migrations table in the relevant database. So, if it doesn't have the number for the migration to create the users table, it will run that migration, which will blow up as you have seen if the table happens to be there already.
I'm not familiar with the tutorial you're talking about - can you take me through what you have done already with your migrations?
It appears there was a problem with one of the other migration files -- I moved that file out of the migrate folder and re-ran rake and it worked.