Rake aborted during postgresql migration - ruby-on-rails

Rails/PostgreSQL newbie here, having real problems dealing with creating PostgreSQL projects in Rails.
Briefly, I am following Ryans excellent Railscast episodes, in particular the episode on deployment. I create a new project like this:
rails new blog -d postgresql
This generates a database.yml file similar to the following (comments extracted):
development:
adapter: postgresql
encoding: unicode
database: blog_development
pool: 5
username: blog
password:
test:
adapter: postgresql
encoding: unicode
database: blog_test
pool: 5
username: blog
password:
production:
adapter: postgresql
encoding: unicode
database: blog_production
pool: 5
username: blog
password:
Looks good so far.
However, on my development machine, whenever I try to run rake db:create:all, I get a message similar to the following:
rake aborted!
FATAL: role "blog" does not exist
My understanding is that this is because I haven't (or, rather, Rails hasn't) created a user called "blog" when the application was created. Therefore, I need to either:
Change the username for all environments to my system's "super
user" I chose when I installed Homebrew (which works); OR
Create a new super user for each individual project I set up (e.g. a
super user "blog" in this instance).
Now, the problem is this - should I be creating a super user for each individual project I create? If so, how? The reason I ask is that Ryan's Railscasts episodes never actually mention this, so I'm not sure if this is the correct approach to be taking (it seems a bit long-winded), or if there is a problem with my PostgreSQL database installation (as I would have thought that the super user would be automatically set up along with the database when the application is created).
Additionally, so as to make deployment easier, I'd like to keep the overall database.yml file the same in both the development and production environments (although I admit to knowing even less about deployment, so maybe this isn't ideal).
Thanks!

Creating database users is up to you. Rails does not create database users.
Depending on your platform, you can use some kind of database management GUI to make it easier to create users and manage their rights. I use PGAdmin, which came with the Mac OS X executable for PostgreSQL. It is available for other platforms as well.
In development, many people use the same "superuser" for all projects. In production, I would advice you to have application-specific users with minimal privileges.
I don't exactly understand the last paragraph about the database.yml being the same for dev and prod envs, because that is precisely the point - one file for all environments. You should probably not use the same credentials for development and production.

Related

Simple way to run rails migrations for a remote database

I have a rails app and want to split off my Postgres database to a remote, managed one rather than the standard local one. It seemed easy enough to configure this— however, now I am trying to run my migrations against this new db and it’s proving more difficult. I’m using Mina to deploy, which calls rake db:migrate as part of the deployment. It does not run the migrations, however, as it says that all migrations are up to date, and my create calls can’t find the tables, so I assume the migrations have not run on the remote db.
Whst’s the best way to accomplish this? Every other answer I’ve found involves adding something like ActiveRecord::Base.establish_connection(db_params) command to the top of every migration and every model. This seems absurd— I have probably a 75 migrations at this point. Is there no better way? Is this even the right approach, or could I also use the generated schemes file somehow?
You can set up your database credentials in database.yml with something like this.
remote:
adapter: postgresql
host: your.remote.host
database: yourdb
username: user
password: pass
pool: 5
timeout: 5000
locale: en_US.UTF8
Then run your migrations like
RAILS_ENV=remote rails db:migrate

Deploy database.yml file with capistrano with multiple database definitions

I have a rails application which needs to connect to two different databases. These database definitions are both in the database.yml file in my repository, with the format:
production:
adapter: ...
database: ...
username: ...
password: ...
secondary-production:
adapter: ...
database: ...
username: ...
password: ...
I have that format for production, staging, and development databases. When running cap deploy or cap production deploy, I need to make both database definitions come through.
I wasn't the person who set up capistrano on this app, and I've never used it before, so I'm finding it hard to work out how to do this. Could anyone point me to a relevant piece of documentation or let me know what file and syntax I need to use for it?
I found the answer.
There was a database.yml.erb file in the /config/recipes/templates folder that I had to update.

Rails 3 - rake tasks to work with multiple database connections

Let's say I have s different database connections...
Right now for the purposes of this example let's only be concerned with development. When I run 'rake db:setup' it only creates development because from the rake task perspective the other connection is another environment. I could pass in the other connection as the RAILS_ENV to create the database. However, the problem comes in with how we've defined our database connections. I'd rather not undo this as it makes management and deployment much easier. What we've done is this...
In our database.yml we've added the following code.
databases_file = File.join(Rails.root.to_s, "config", "databases", "#{Rails.env.to_s}.yml")
IO.read(databases_file) if File.exist?(databases_file)
Then in a databases sub-folder under config we've created the different environment yml files.
So in development.yml we have...
development:
... details ...
logging:
... details ...
Now if I set RAILS_ENV to 'logging' it will never load the file since the file is called development.yml. Thus it will never find the logging connection.
If I consolidate all these settings back into the database.yml file then we're back to not checking in the database.yml into the git repo and having to manually create it on the development machines for new hires and such. We'd also have to change our deploy process to start putting the file in place on the lower environments. (Our production process already supports this)
You could use environment variables to manage these. You could have a single database.yml with things defined such as:
development:
database: ENV['DEVELOPMENT_DATABASE']
And then set the environment variables in your .bashrc/.zshrc.
We have multiple databases and we use branches heavily... so I came up with this solution to create multiple databases and tie their names to the branch being worked on...
# config/database.yml
<%=
databases_file = File.join(Rails.root.to_s, "config", "databases", "#{Rails.env.to_s}.yml")
if Rails.env.development? || Rails.env.test?
branch = ENV['BRANCH'] || `git branch --no-color 2> /dev/null`.chomp.split("\n").grep(/^[*]/).first[/(\S+)$/,1].sub("-", "_")
puts "Using databases for #{branch}"
IO.read(databases_file).gsub!("<branch>", branch) if File.exist?(databases_file)
else
IO.read(databases_file) if File.exist?(databases_file)
end
%>
And then you create a database file for each environment. In the development.yml and test.yml you use the token to let this script look for what it needs to in order to do replacement. So an example file would look like this.
# config/databases/development.yml
development:
adapter: mysql2
host: 127.0.0.1
database: <branch>_dev
username: user
password: pass
versions:
adapter: mysql2
host: 127.0.0.1
database: <branch>_versions
username: user
password: pass
reporting:
adapter: mysql2
host: 127.0.0.1
database: <branch>_reporting
username: user
password: pass
ods:
adapter: mysql2
host: 127.0.0.1
database: <branch>_ods
username: user
password: pass
I then extended the rake tasks to handle multiple databases
This is where most of the work went in. Therefore, I'm going to leave it out of the answer and make you work for it! No actually, it's just a big large mess that I'm not proud of and would love time to fix it, but haven't found any. I don't want to lead anyone down the wrong path but if you have questions just get me a message and I'll be happy to help.

Database not being selected in rails project when attempting to rake db:migrate

Working with a rails app, having some manner of weird database / rake issues.
When I execute:
rake db:migrate
I am getting the following error:
Mysql2::Error: No database selected: SHOW TABLES
(See full trace by running task with --trace)
The trace isn't revealing much useful information. Can be seen here: http://pastebin.com/WdsguudC
The config file looks right, and the user is getting logged in, or I would have gotten some kind of access error. The database exists, the user has correct permission, and I can access and manipulate it manually. I have done a bunch of googling, and haven't found anything helpful. Not sure if there is any other code that needs provided, because this seems like fairly low level problem.
after all that it was a spacing issue in the yaml.
Note that ruby has exchanged its YAML parser in a recent 1.9.2 version.
This might also cause this problem.
In order to switch back to the old YAML parser syck, use this in boot.rb:
require 'yaml'
YAML::ENGINE.yamler= 'syck'
Well, it is a common issue for us beginners. This issue comes from the moment when you create your new project in rails. Let’s say to have an example
$ rails new toy –d mysql
After you do the bundle and start your server, most likely you will have an error. To correct it you need to go to your database.yml and modify the following:
Add a password in the password field as shown below, this is the password you use to secure mysql.
default: &default
adapter: mysql2
encoding: utf8
pool: 5
username: root
password: mypassword
socket: /tmp/mysql.sock
Also, comment out the database adding a hash tag (#)before the name as shown below
development:
: *default
database: #toy_development
Then restart your command line and go to the root of your application and type:
$ rails s
You have to see the Ruby on Rails welcome page..
After, you need to create a database.
Create a DATABASE.
The issue message is saying that not DATABASE is selected. It is because I didn’t create one. When you work with MySQL you have to create one, so:
Go to the root of my application and type:
$ mysql –u root –p
$ Passwor: mypassword (Enter your password, this is the one you entered to secure MySQL)
Note: This example works wit a project called toy and the user I wanted to grant privileges is mark and the password I’ll give is 45mark. Below you will see where I apply these elements. Remember to apply your own elements on each part of the statement.
Create and user for this project
Once you are in, you will see the pointer (mysql> ), so type after it:
mysql> GRANT ALL PRIVILEGES ON toy_development.* TO 'mark'#'localhost' IDENTIFIED BY '45mark';
Then type:
mysql> exit;
Check that it is working by typing:
$ mysql –u mark –p toy_development
Enter password: 45mark (You enter the one you gave)
Open database.yml file and configure what is needed and fix as required. In my case I will chance the username to mark and the password to 45mark
default: &default
adapter: mysql2
encoding: utf8
pool: 5
username: mark
password: 45mark
socket: /tmp/mysql.sock
- Also, REMOVE the hash tag (#) added before
development:
: *default
database: toy_development
Save it.
Go to the root of the application and type
$ rake db:schema:dump
Done!!
I hope this helps. Happy coding!!
Thanks
I had the same issue with ruby 1.9.2-p180 , upgraded to p290 and it works
Just restart the server; in the command line:
Press Ctrl + C
execute:
rails s
I had a similar error when i typed rake db:schema:dump and it turns out that I just have to comment out all the databases on my yaml file except my development one.
Give a try to this.
rake db:test:prepare
Install this to see if you have actually created a table or not. Open the "development.sqlite3" in db folder
http://sqlitebrowser.org/
Its a simple error checkout the entire database.yml file and see that where is default decription is given database name is given or not if not then look below it there will another development name is also given where configuration of database is use check that give your database name in it
default: &default
adapter: mysql2
encoding: utf8
pool: 5
username: root
password: 12345
host: localhost
development:
<<: *default
database: db_name
One potential cause is that there is a DATABASE_URL environment variable defined.
$ echo $DATABASE_URL
=> mysql2://root#localhost:3306
If you get a similar output to the above url (i.e., the database name is not present), then you might want to add the database name to the string or unset the env var.
$ export DATABASE_URL=mysql2://root#localhost:3306/my_rails_app_development
$ unset DATABASE_URL
If you unset the var, you probably want to specify the database details in database.yml instead.

Using an existing database of another Rails application in a new Rails application

I'm new to Rails. I had created a Rails application earlier and also collected a few data records in the development database. Suppose, I create a new Rails application and I prefer to use the existing development database of the 1st Rails application in my newly created Rails application, how do I do that?
Just change the file config/database.yml and set the database name.
your database.yml should look like this:
development:
host: localhost
adapter: mysql
database: your_database_name [just the name, not the path]
username: your_username
password: your_password
test:
...
production:
...
You need to change the database name in the database.yml file.
The seconnd problem you run into is migrations.
I would copy the migrations form your previous application over so that you maintain migration integrity with version numbers and rolling back if that is needed.
Also, if you are seeing development.locs - that locs refers to the table_name, which in restful context is usually also coincidentally the name of the controller.

Resources