Using with Rails
Rails 3.x and 4.x:
Add Vanity to your Gemfile:
Once the gem is setup, enable Vanity in your ActionController:
class ApplicationController < ActionController::Base use_vanity :current_user end
This example assumes you have a
current_user controller method which will return a consistent value for each user.
There are other ways to identify people as well, you can read more about the options in Managing Identity.
When collection is off, Vanity doesn’t connect to the database server, so there’s no need to set a database configuration for these environments.
Overriding default views
If you would like to customize Vanity’s dashboard, you can create create copies of the default views in
app/views/vanity by running a generator:
rails g vanity:views
You can then edit them to your heart’s content. If you need to use an alternative location for your custom templates, set the configuration variable
Vanity.playground like this:
Vanity.configure do |config| config.templates_path = 'views/vanity' end
Unicorn and Forking Servers
Unicorn forks the master process to create worker processes efficiently. Since the master processes opens a connection to the database, all workers end up sharing that connection, resulting in ugly contention issues.
The cure is simple, use the
after_fork hook to reconnect each worker process. Here’s the relevant part from my
after_fork do |server, worker| ActiveRecord::Base.establish_connection Vanity.playground.establish_connection end
You’ll run into this issue with other forking servers like Passenger as well.