I recently had a short term project served off of Heroku that approached 10,000 Postgres records and needed to be upgraded from hobby-dev to hobby-basic. Being new to Heroku, I did my best in finding out how to do so and followed heroku's upgrade using PG Backup guide. With a bit of trial and error, I thought I got it working. I erred on the side of caution and didn't do the last deletion of the old DB step. However, I soon got a message from Heroku telling me I've passed the 10,000 record limit. I went to my Heroku dashboard and checked out the DB size. It doesn't look like the Hobby-Basic DB had anything stored in it. I waited a couple weeks and checked again, thinking it may have been a realtime updating issue. Still no tables in the new Hobby-Basic DB.
So my question is, is there a way for me to find out which DB my Heroku app is set up to use currently? How do I force it to switch to a different DB in my app?
This is the guide I followed to upgrade from Hobby-Dev to Basic: https://devcenter.heroku.com/articles/upgrade-heroku-postgres-with-pgbackups
Presumably your app is reading from the environment variable DATABASE_URL. If you have multiple database then you should also have other environment variables like HEROKU_POSTGRESQL_(color). You can access those environment variables from within your app to inspect the configured database information, and you can change them in the Heroku panel. If you change DATABASE_URL to one of the values of HEROKU_POSTGRESQL_(color), then your app should pick up on that and switch to the different database. You can also edit your configuration and access another environment variable while bypassing DATABASE_URL entirely.
Related
I am working on an app where I now need to add test mode or sandbox mode features like Stripe provides in the dashboard. In this feature, when the user turned the test mode on, the user can test the functionality and can create dummy data in the same login session/token.
I have tried to use the Rails 6 feature to use multiple databases but have a few questions:
is it good to switch the connection in production for test mode even we will not have many test requests?
will it be good to have a separate instance for test mode with the test subdomain? in this case how we should manage the login sessions? should we copy data to the test the database? will it be good and common practice?
I only can manage to implement this if I have user data in the test database so that when I switch database connection system will not send an unauthenticated response.
Note:
for login and user update, it will use the primary database all time and for other actions, it will use the test_mode database. I am doing this by skip_around_action in a specific controller.
We are doing this so that when the user turned off test mode, it will update the primary database and the next request will use the primary database as per around_action logic
Here is my current code in application_controller.rb:
around_action :setup_db_connection
def setup_db_connection
database_key = (user.test_mode?) ? :test_mode : :primary
ActiveRecord::Base.connected_to(database: database_key) do
yield
end
end
test_mode database key has test database configuration in database.yml and similarly for primary database key. Both are completely two different databases.
Can anyone please tell me if I am going in to correct direction? Any help or thought will be appriciated. Thank you in advance!!!!
You should just create an additional environment as this is the exact problem that they are designed to solve.
Rails just ships preconfigured with development, test and production as thats the bare minimum you can get by with. You can actually have an unlimeted number of environments.
So lets say you want to create an enviroment named staging which closely matches your production environment. You can start by copying the productions settings:
cp app/environments/production.rb app/environments/staging.rb
And then just setup an additional hash in your database.yml and credentials files.
staging:
<<: *default
database: my_app_staging
You can then set the environment by using the RAILS_ENV env var or the command line arguments when starting the Rails server. Your staging environment can be run for example in a separate Heroku application made available on a subdomain. If you're using Heroku or some other SAAS platform a hobby tier will often be sufficient for staging.
When it comes to data you can either work on a set of dummy data generated by wiping and seeding or regularily wipe the staging database with a backup from your production database.
I would not consider using a "test mode switch" a good idea as it makes far to easy to inadvertantly mess things up. Using a separate environment lets you use a completely different set of credentials as well so you won't accentially do something like create a real credit card charge or destroy data on third party services. Sandboxes should be isolated.
I've added heroku postgres addon.
The DATABASE_URL is something like postgres://xxxxxxxxx:xxxxxxxx#xxxxxxxxx.compute-1.amazonaws.com:5432/ddo2ahvosfggq
I want the database name to be like my_app_database. I want to rename ddo2ahvosfggq to my_app_database.
How can I do that?
Can I use ALTER DATABASE? http://www.postgresql.org/docs/9.1/static/sql-alterdatabase.html
There is already a question in StackOverflow How to rename database in Heroku?
But the answers is to rename the app. I don't know how renaming app will work?
If my_app is the name of my heroku app. Will the below DATABASE_URL work?
postgres://xxxxxxxxx:xxxxxxxx#xxxxxxxxx.compute-1.amazonaws.com:5432/my_app
You can't. It's a Database-as-a-Service (DBaaS) and database name is not customizable there. You just get it from the service and use. Since it's not a user-facing detail for web applications, pretty names are of no use. So why bother?
Most actions you can do with your database are listed on Heroku Postgres website. You can:
regenerate credentials (that don't include database name, only username and password)
wipe the database (that doesn't rename the database as well, just drops the tables)
create one more database (but it will be named randomly, just as all the others)
You don't ever really need to type in the name of the production database on Heroku.
Heroku has a post commit hook which writes the production DB details into /config/database.yml.
If you ever really need to to query the database without a model you would establish a connection by:
ActiveRecord::Base.establish_connection
query = ActiveRecord::Base.connection.execute('SELECT * FROM foo;')
As part of the security procedures for our Rails application, we want to have an audit log of the commands that were run from rails console in our production environment.
This audit log should be persisted somewhere, such as a database, a file in an S3 bucket, or similar. If it could be written to the standard rails log, that might be OK too, as we already have a way to persist that.
We're currently hosted on Heroku. Heroku will log the event of firing up a console, but (a) Heroku provides no functionality for logging commands run from an active console, and (b) we'd like a more general-purpose solution.
Are there any pre-existing solutions for this out there?
If there is none, I'm trying to figure out how to monkey-patch IRB or Rails Console.
I've discovered that the data I need is already in
Readline::HISTORY
but I'm struggling to figure out where/how to hook into it.
Ideally, I'd like to capture each entry as (before?) it is sent to the interpreter, and quickly persist it somewhere (we already have Resque, so that may be a good solution). FWIW, sending the contents of Readline::HISTORY on Kernel.exit seems like it may be unreliable. For example, if a SIGKILL stops the process, then the history contents wouldn't be saved.
In my rails 4 application directory, I typed "heroku pg:credentials DATABASE" into terminal to get all the information about the database for my application which is deployed on heroku. Since I'd like to view the data inside my postgresql database, I tried inputting the information into Induction, but it ended up not responding and I was forced to enter the activity monitor and force quit. I followed the same procedure several more times all with the same result. Is my version of Induction faulty? Should I be using a different program to view my database? Or am I doing something wrong?
I'm new to rails, so thanks for your help!
Yes, you can. Heroku Postgres allows connections from outside Heroku's network. The credentials displayed from heroku pg:credentials will be all you need and should work. Maybe try using the official PGAdmin tool instead?
I'm building a system which allows the user to modify the database.yml contents via an admin frontend interface.
That changes to database.yml obviously don't have any affect until the application is restarted. Rather than forcing the user (who may not have SSH access to the physical box) to restar the application manually, I'd like a way to force ActiveRecord to reload the config post startup.
Rather than requiring them to restart the server, is there a way to force ActiveRecord to re-initialize after initial startup?
Rationale
There are two use cases for this - a) initial setup wizard b) moving from sqlite evaluation database to production supported database.
Initial Setup Wizard
After installing our application and starting it for the first time the user will be presented with a setup wizard, which amongst other things, allows the user to choose between the built in evaluation database using sqlite or to specify a production supported database. They need to specify the database properties. Rather than asking users to edit yml files on the server we wish the present a frontend to do so during initial setup.
Moving from sqlite evaluation database to production supported database
If the user opted to go with the built in evaluation database, but alter wants to migrate to a production database they need to update the database settings to reflect this change. Same reasons as above, a front end rather than requiring the user to edit config files is desired, especially since we can validate connectivity, permissions etc from the application rather than the user finding out it didn't work when they try to start the application and they get an activerecord exception.
Restart your Rails stack on the next request just as you would if you had access to the server.
system("touch #{File.join(Rails.root,'tmp','restart.txt')")
Building on #wless1's answer in order to get ERB-like ENV vars (e.g. <%= ENV['DB_HOST'] %>) working try this:
YAML::load(ERB.new(File.read(File.join(Rails.root, "config/database.yml"))).result)
ActiveRecord::Base.establish_connection config[Rails.env]
Theoretically, you could achieve this with the following:
config = YAML::load File.read(File.join(Rails.root, "config/database.yml"))
ActiveRecord::Base.establish_connection config[Rails.env]
You'd have to execute the reconnection code in every rails process you're running for it to be effective. There's a bunch of dangerous things to worry about here though - race conditions when changing the database config, syntax problems in the new database.yml, etc.