New to rails here, and experimenting with using the db\seeds.rb file and such
First, I want to clear all the data in my database using rake db:reset but it's not working!
Here's my output
C:\Sites\sportproject>rake db:reset
Couldn't drop db/development.sqlite3 : #
db/development.sqlite3 already exists
-- create_table("sports", {:force=>true})
-> 0.0640s
-- create_table("teams", {:force=>true})
-> 0.0340s
-- add_index("teams", ["sport_id"], {:name=>"index_teams_on_sport_id"})
-> 0.0160s
-- initialize_schema_migrations_table()
-> 0.0000s
-- assume_migrated_upto_version(20130531012951, ["C:/Sites/sportproject/db/migra
te"])
-> 0.0000s
Then I log into my console with rails console and type Sport.all (Sport is the name of one of my models) and it's showing there's still data!
What am I doing wrong?
I found the answer in Patrik's link.
It's because I'm on windows, as the database is possibly being used by another process, hence the "Permission Denied" message. I just needed to ensure no other processes were using the database.
If you are using Linux and postgresql you can do
sudo service postgresql restart
and then
rake db:reset
I think with mysql is
sudo service mysql restart
I had the same problem. The reason was because I was running the rake db:reset on my IRB or Console. Instead, I quit out of console and run the code again and it worked. Perhaps Itll work for you too.
Related
I am trying to reset my development Database for my Rails 5.0 project on Windows, but when I run (same as rake db:drop)
rails db:drop
I get the following error:
Errno::EACCES Permission denied # unlink_internal
I restarted my PC already to make sure that rails was not running in anyway
You just need to exit the Rails Server.
I had the same error trying to reset my sqlite3 db on Windows, using rails 5.1.6 while doing the Learn Enough to Be Dangerous Rails tutorial. I found the following answer on another post, and it worked for me:
"For Dropping entire database just give rake db:setup it drops and again creates the database for you."
When I run the command, I get:
$ rails db:setup
Database 'db/development.sqlite3' already exists
Database 'db/test.sqlite3' already exists
-- create_table("users", {:force=>:cascade})
-> 0.0497s
-- create_table("users", {:force=>:cascade})
-> 0.0624s
And my database seems to work as expected, but with no data.
This can help
When I need to remove data base then I use rake db:reset.
Please try it.
Hope it helps.
Found Solution:
In windows machine you would have to specify that it is an unsafe move, so i
rake db:drop_unsafe
rails db:migrate
this is for windows machine, if you're using Linux then you can do just
rake db:reset
Trying to get my rails up and running but am having a problem. When creating my new rails app on the command line I ran the usual
rails new PhotoApp -d postgresql
Generated my core scaffold. Then generated a model with attributes in the terminal and that was fine. After creating my model I first ran rake db:create and that returned a long log of characters with at the top telling me FATAL: role "PhotoApp" does not exist so then I tried rake db:migrate and that didn't work either returning me
rake aborted!
PG::ConnectionBad: FATAL: role "PhotoApp" does not exist
/Users/##$%^$#/Code/Projects/PhotoApp/config/environment.rb:5:in `<top (required)>'
Tasks: TOP => db:migrate => environment
(See full trace by running task with --trace)
WTF is going on here?
Thanks for any help.
The error is telling you that Postgres isn't finding your app. What does your database.yml file look like?
I would first run the rake task again, using the --trace as suggested:
rake db:create --trace
That will give you a more verbose tracing, so you can try to isolate the problem.
From experience I can tell you though that 'Roles' in Postgres can be a nightmare. How did you install Postgres on your machine? HomeBrew? The Postgres App?
Please post the full trace, as well as your database.yml file. This will help better assess the problem!
I'm using Capistrano to deploy to production for the first time, and I'm getting an error when I run
cap production deploy
The error is:
** Invoke deploy:migrate (first_time)
** Invoke deploy:set_rails_env
** Execute deploy:migrate
DEBUG [048f89c6] Running /usr/bin/env if test ! -d /home/deployer_user/apps/ap_production/releases/20140209005208; then echo "Directory does not exist '/home/deployer_user/apps/ap_production/releases/20140209005208'" 1>&2; false; fi on eslope.net
DEBUG [048f89c6] Command: if test ! -d /home/deployer_user/apps/ap_production/releases/20140209005208; then echo "Directory does not exist '/home/deployer_user/apps/ap_production/releases/20140209005208'" 1>&2; false; fi
DEBUG [048f89c6] Finished in 0.160 seconds with exit status 0 (successful).
INFO [52f75214] Running ~/.rbenv/bin/rbenv exec bundle exec rake db:migrate on eserver.net
DEBUG [52f75214] Command: cd /home/deployer_user/apps/ap_production/releases/20140209005208 && ( RBENV_ROOT=~/.rbenv RBENV_VERSION=2.1.0 RAILS_ENV=production ~/.rbenv/bin/rbenv exec bundle exec rake db:migrate )
DEBUG [52f75214] rake aborted!
DEBUG [52f75214] An error has occurred, this and all later migrations canceled:
DEBUG [52f75214]
DEBUG [52f75214] PG::UndefinedTable: ERROR: relation "client_infos" does not exist
DEBUG [52f75214] : ALTER TABLE "client_infos" RENAME TO "clients
The error actually makes complete sense. The referenced table doesn't exist. What I don't understand is why the migration is running at all? Why isn't the the database just being created from the schema on the first run. Did I inadvertently remove a file that says what migrations have been run? Either by just deleting it, or by ".gitignoring" it?
I think I know how I can fix it (rake db:create or similar) but what I don't understand is, if in Capistrano v3 it knows it's a first time, why it would not use the schema directly rather than run all the migrations? I'm a noob, that seems reasonable, but on the other hand, running the migrations would achieve the same result, so... (But what about folks who don't what to use the migrations blindly in production; won't they be stuck?) Thanks.
Ultimately what I did was as lmars and Nick suggested. I ran something like this directly on the production machine:
RAILS_ENV=production bundle exec rake db:drop
RAILS_ENV=production bundle exec rake db:schema:create
RAILS_ENV=production bundle exec rake db:schema:load
This destroys the data in the datbase of course, but on first deploy, that's not an issue.
I would think there's an easier way, but... I don't know it.
db:migrate takes the migration files and executes them.
so if a table doesn't exist, it will tell you that so. If your deploy is the first deploy to that machine, or that the DB configured is yet have been initialized you should do:
Create DB
rake db:create
this is will create all tables
2 Run the Migrations
`rake db:migrate`
Here obviously, you need to have migrations in place.
It is highly recommended not to load a schema (unless you have no choice) since its hard to work on the schema after (rollbacking, etc) but if you have no choice you can do rake db:schema:load
see this for more info
rake db:schema:load vs. migrations
How to update production database schema safely in rails 3.1.3?
Check your database.yml config, production part, if it is correct. Then ensure Postgresql server is running on the production server and the application (as a user) has access rights. I assume "deployer" is the user, so check this user has all the necessary rights.
From the error it looks like you are trying to rename the client_infos table to clients but the client_infos table does not exist, but do you not have an earlier migration which created the client_infos table?
If you don't have a migration which creates the client_infos table, then where did it come from? Did you create it manually? All changes to the database should have an accompanying migration.
If you do have a migration for the client_infos table, the schema_migrations database table (which is where Rails keeps a record of what migrations have run) may of somehow got out of sync. Given you are deploying for the first time, its probably worth dropping the whole database and starting again.
What I don't understand is why the migration is running at all? Why isn't the the database just being created from the schema on the first run
If written correctly, the migrations should have the same effect as loading the schema, they will just do it incrementally. You can of course manually load the schema if you wish, but Capistrano will not do this as it is quite a dangerous thing to run (you likely never want to recreate your production database)
So I'm using Heroku Postgres in my Rails app, but I'm not hosting my app on Heroku itself. I used the Active Record connection details from Heroku in my database.yml, and it looks like this:
development:
adapter: postgresql
encoding: unicode
pool: 5
database: [database]
username: [username]
password: [password]
host: ec2-54-227-243-78.compute-1.amazonaws.com
port: 5432
However, now I'm trying to rake db:migrate my app so the database gets all set up with my models. Running that command doesn't do anything, so I tried rake db:reset and I get this:
Couldn't drop df2cokjfj0k4vu : #<PG::Error: FATAL: permission denied for database "postgres"
DETAIL: User does not have CONNECT privilege.
df2cokjfj0k4vu already exists
-- initialize_schema_migrations_table()
-> 1.3997s
-- assume_migrated_upto_version(20130924040351, ["/home/action/braindb/db/migrate"])
-> 0.0882s
Any idea what I'm doing wrong. I'm still pretty new to Rails so sometimes I forget how to get my Postgres database setup properly when migrating hosts.
Use heroku pg:reset DATABASE instead as noted in https://devcenter.heroku.com/articles/rake
You cannot drop databases in Heroku with rake db:reset because user has no privileges.
You can't drop your PG database on Heroku.
I recently had this problem and resolved it through the following steps.
heroku pg --help gets the name of commands for using postgres
heroku pg:reset DATABASE # resets the db
Answer the prompt to confirm
Like others I had a similar problem but running pg:reset did not help: that's where I ran into the user does not have CONNECT privilege issue.
1) heroku pg:reset you will be prompted to enter the project name to confirm.
2) From Heroku's docs run heroku rake db:schema:load
I had the same problem. I fixed it by running:
heroku pg:reset DATABASE
(note: must specify DATABASE as above)
If you got this because you were running rake db:create, instead, simply skip to the migration. For whatever reason, postgresql on heroku doesn't require the rake db:create step as may be required on local installations.
In other words, instead of
heroku run rake db:create db:migrate db:seed
run this instead
heroku run rake db:migrate db:seed
The solution to me was to just go straight to migration because the database is already created (don't go on "heroku run rails db:create")
heroku run rails db:migrate -a YOURAPPNAME
For one of my apps, upgrading to the first paid tier of a Heroku database seemed to work for me: https://devcenter.heroku.com/articles/upgrade-heroku-postgres-with-pgbackups#provision-new-plan
Reason was that 'heroku pg:info' revealed that I was over my row limit as shown here:
Rows: 12392/10000 (Write access revoked)
I'm testing a Rails/Spree app on appfog, but I can't get the DB to seed.
I've followed these instructions to the T:
https://docs.appfog.com/languages/ruby/rails
But at the point where I run af tunnel and then open a new terminal window, then run RAILS_ENV=proxied-appfog rake db:seed I get the error
loading fixture /var/lib/gems/1.9.1/gems/spree_core-1.3.2/db/default/spree/countries.yml
rake aborted!
Mysql2::Error: closed MySQL connection: SET FOREIGN_KEY_CHECKS = 1
I'm using MySQL for the db.
Any thoughts on why this is happening?
rake:db migrate runs with no errors.
rake:db reset fails with the same error.
Maybe you run af tunnel, but it is incomplete. You have to run some like af tunnel my-app-mysql-1234 and then select 1 option (none)
Check my recent answer and change the RAILS_ENV=production rake db:migrate per some like RAILS_ENV=production rake db:seed
App Fog Rails Migrate Database
Its work fine for me.
Good luck!