Rails DB Migration - permissions - ruby-on-rails

I'm a Rails novice, but am currently trying to modify an existing application that I inherited.
I'm running some db migrations that create new tables on our staging server (Not local machine) and all the new DB tables create seem to have different permissions than the tables already created.
I am running "rake db:migrate VERSION=20110213100531 RAILS_ENV=staging" with one sshlogin and I have my sql login defined in my database.yml under staging as separate mysql database login.
Is there any particular settings/user I should be running my db migration under?

From what you've said I think most likely your problems are being caused from the way you have your user permissions set up in the remote database. This is not something that can be altered from the rails side.
Your database.yml file will just specify your login details into that database, but it's up to you to modify your user permissions settings in your database.
If you've got admin access into your database, I'd start by comparing the previous user's permissions to your own and seeing what's the difference.
All the best

Related

Access to database tables location created with migrate in Rails

I did a homework on Rails using RubyMine.
I need to submit the homework with the database tables . But I can't access database tables file location, because I don't know under the which folder I created with migrate. I have migrated tables at the rubymine terminal
I used postgresql for database.
I will be so happy if you could help me. Thank you from now.
There is a schema.rb file that represents your database under db/ folder. So this is the answer for your first question.
The answer to second question is in order to deploy your code on a different computer, the third-party softwares need to be installed. In your scenario, this third-party is postgres as db server. To deploy your code, just type on your terminal rake db:setup. This command will create your database, run migrations and finally seed your database if db/seed.rb contains something. As a result, after rails s there should be some output.
It is worth to note that Rails is db agnostic framework. If you did not use postgres specific features then you would use mysql or sqlite on different computers/servers. But keep in mind that you should change the adapter from config/database.yml if you want to use another database.
Ödev sunumunda başarılar.

Rails: Migration and database differences between development and production

I recently deployed a website to heroku and I am having problems with the database. I am using ruby on rails and when I first created my local databases I used SQLite. When deploying to heroku I had to change my databases to Postgres and in the process several migration files got removed and changed into a single migration. Now, when I run the postgres database on my localhost, I am still seeing all of the columns in my database, but when I visit the page on heroku one of the columns is missing.
I have checked both my local console and the heroku console and the databases are now different. The local console includes all of the columns in the database and the heroku console is missing one of the columns in the database, but is generating all of the other columns correctly. I have tried running a rake task on heroku and have pushed the most recent changes to heroku.
I tried to to add an additional migration to add the missing column to the database, but whenever I try to rake the migration it tells me that attribute already exists. Any help I can get is appreciated!
The best way to set up your database on heroku is with
rake db:schema:load
From the guides on migrations
Migrations, mighty as they may be, are not the authoritative source
for your database schema. That role falls to either db/schema.rb or an
SQL file which Active Record generates by examining the database. They
are not designed to be edited, they just represent the current state
of the database.
There is no need (and it is error prone) to deploy a new instance of
an app by replaying the entire migration history. It is much simpler
and faster to just load into the database a description of the current
schema.

PostgreSQL load existing project's db

i'm setting up a RoR project and i've got a database.yml file with a specific database with user and password. What i did was to add this file into my project and want to load it. when i run rails s i get an authentication error for the db user. Should i create a new user? should i create the db? Thing is i want to load the records that already exists on it, that's why i'm a little bit lost.
Important fact: i already have a user created with a specific password (for another db) and the username for the new db is the same as my old user (with different password). Would that be a problem?
A database user can have only one password. Change the password in your database.yml to the password of your existing database user.
You have to create the database user that's specified in the database.yml file.
For Postgres, you have to use createuser for this. You'll also have to set the corresponding password and then add the proper privileges.
This might help: https://www.digitalocean.com/community/tutorials/how-to-use-roles-and-manage-grant-permissions-in-postgresql-on-a-vps--2.
Then you can run bin/rails s. The records won't be deleted.

Rails migrations & PostgreSQL: separate user for migration and setting privileges for production user

I have two users in postgresql one of which is called migration and is used when Rails runs migrations on the production server. This user owns the production database. I also have production user who is supposed to have only the following privileges: SELECT, INSERT, UPDATE, DELETE on the production database.
Problem is, every time a new table is created, I have to manually run this in psql:
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO production;
-- next line is needed for each new table which has an auto incrementing field, in this case - table `users`
GRANT USAGE, SELECT ON SEQUENCE users_id_seq TO production;
because permissions for production user on newly created tables are not set automatically. What's the best way to do it automatically when running migrations? Any script available for Rails/Capistrano?
You could use Postgres' ALTER DEFAULT PRIVILEGES to have it automatically assign the rights to production for all newly created tables.
Alternatively, you could write a custom Capistrano task to set the permissions that is called through the after "deploy:migrate", "mycustomtaskname" hook. This pastie might give you a few good hints on how to interact with pgsql through Capistrano, for example how to provide the password interactively.

Running DB Migrations from application

I have a rails application where each user has a separate database. (taking Joel Spolsky's advice on this). I want to run DB migrations from the rails application to create a new database and tables for this user.
What is the easiest way to do this?
Maybe the db migration is not the best for this type of thing. Thanks!
It would be nice if it could be a completely automated process. The following process would be ideal.
A user signs up on our site to use this web app
Migrations are run to create this users database and get tables setup correctly
Is there a way of calling a rake task from a ruby application?
To answer part of your question, here's how you'd run a rake task from inside Rails code:
require 'rake'
load 'path/to/task.rake'
Rake::Task['foo:bar:baz'].invoke
Mind you, I have no idea how (or why) you could have one database per user.
We use seperate configuration files for each user. So in the config/ dir we would have roo.database.yml which would connect to my personal database, and I would copy that over the database.yml file that is used by rails.
We were thinking of expanding the rails Rakefile so we could specify the developer as a environment variable, which would then select a specfic datbase configuration, allowing us to only have one database.yml file. We haven't done this though as the above method works well enough.
Actually I have discovered a good way to run DB migrations from an application:
ActiveRecord::Migrator.migrate("db/migrate/")

Resources