Eric Pugh
Category: Uncategorized
The biggest slam against using file based databases like SQLite is that they are actual files embedded in your application, and that you have to go through extra hoops when upgrading your application. For example, if you have your production prod.sqlite3 file in ./db, then every time you update your application using Capistrano youll replace your production database with a fresh one!
nn
Well, my first attempt to work around this involved excluding the ./db directory from checkout and then creating a db directory in /shared/db. Symlinking from /shared/db to ./db worked, but was clumsy, and required extra code in my deployment recipe.
nn
A light bulb finally dawned that the path in databases.yml for my production database could be something like:
nn
production:nadapter: sqlite3ndatabase: ../../shared/db/prod.sqlite3nnn
Just go up two directories and over to the shared/db directory and locate the database file there! I tried it out, and it worked great. I ran cap deploy_with_migrations and soon enough had a shared sqlite3 database. I then fired up the app with cap cold_deploy and everything ground to a halt 🙁 . I was getting an error about “database cant be opened. Eventually, after pulling my hair out I discovered that while starting mongrel with ./server/script works great with relative paths to the database, starting with mongrel_rails requires a complete path:
nn
production:nadapter: sqlite3ndatabase: /opt/apps/horseshow/shared/db/prod.sqlite3nnn
Victory at last!
nn
To automate the generation of the shared/db directory, just add to your deploy.rb recipe:
nn
desc 'A setup task to put shared system, log, and database directories in place';ntask :setup, :roles => [:app, :db, :web] donrun n