Rails Spree project - Database inaccessible from other contributor on Git

Question

Ι have started a Rails Spree project along with a friend, and we use GitHub for version control.

I have created the sample project in my machine, and installed Spree functionality on it. This creates a database with sample products, like so:

When my friend clones the project in his machine and imports it, running rails server fails with MigrationException and asks him to run rake db:migrate.

Running rake db:migrate fails after a few migrations, on nonexisting db column.

rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:

SQLite3::SQLException: no such column: spree_calculators.deleted_at: SELECT  "spree_calculators".* FROM "spree_calculators" WHERE "spree_calculators"."deleted_at" IS NULL  ORDER BY "spree_calculators"."id" ASC LIMIT 1000C:in `find_each'
C:/Users/User/xylino/xylino_serena/db/migrate/20151011115236_migrate_old_preferences.spree.rb:15:in `migrate_preferences'
C:/Users/User/xylino/xylino_serena/db/migrate/20151011115236_migrate_old_preferences.spree.rb:4:in `up'
C:in `migrate'
ActiveRecord::StatementInvalid: SQLite3::SQLException: no such column: spree_calculators.deleted_at: SELECT  "spree_calculators".* FROM "spree_calculators" WHERE "spree_calculators"."deleted_at" IS NULL  ORDER BY "spree_calculators"."id" ASC LIMIT 1000
C:in `find_each'
C:/Users/User/xylino/xylino_serena/db/migrate/20151011115236_migrate_old_preferences.spree.rb:15:in `migrate_preferences'
C:/Users/User/xylino/xylino_serena/db/migrate/20151011115236_migrate_old_preferences.spree.rb:4:in `up'
C:in `migrate'
SQLite3::SQLException: no such column: spree_calculators.deleted_at
C:in `find_each'
C:/Users/User/xylino/xylino_serena/db/migrate/20151011115236_migrate_old_preferences.spree.rb:15:in `migrate_preferences'
C:/Users/User/xylino/xylino_serena/db/migrate/20151011115236_migrate_old_preferences.spree.rb:4:in `up'
C:in `migrate'
Tasks: TOP => db:migrate
(See full trace by running task with --trace)

After that, running rails server again is succesful, but no products or other items can be seen in his sample page, like so:

There has to be something wrong with the database. Parts or all of it are inaccessible, possibly due to security issues because we're sharing the db, but I cannot find a solution. Or maybe it's just a botched migration problem

Any ideas?

Burschenschaft

you are not supposed to have a shared db in development, seeds are the way to go – Cabinetmaker

Answer 1

Rails migrations can sometimes get out-of-date with your live environment. This can happen if you have a separate database team that updates your production environment and forgets to make a migration for it. It can also happen if you update your migrations, forget to re-run them, or somehow get in an inconsistent state.

The best way to do this, is for a new developer on a project to run rake db:schema:load. This will load the database structure from your db/schema.rb file, which will have everything as up-to-date as possible. Afterwards, you can run rake db:migrate just to verify everything is migrated.

However, after that, you will have the structure of the database, but not the content of the database. So say you have a users table with [email protected] as a user. Your colleague will have a users table with no users in it.

To fix that, you can edit the db/seeds.rb file. In there, you can do stuff like:

User.create(name: 'Dimitris Sfounis', email: '[email protected]', password: 'password123')
User.create(name: 'Some Colleague', email: '[email protected]', password: 'password123')
Product.create(name: 'Ruby on Rails Tote', price: 15.99)
Product.create(name: 'Ruby on Rails Bag', price: 22.99)

The idea here is that you create demo data, enough to get up and running and testing stuff in a brand new and empty database. With that in place, rake db:seed will provide enough data to run the app.

If that is not good enough, and you want exact copies of the database for all the developers, you could upload your SQLite database and have each of them download a new copy when they pull the database down. However, this is tough to manage, because each time someone updates the master branch with a new migration, you'll need to update the SQLite file. For other databases, you can dump and restore with pg_dump (Postgres) or mysqldump (MySQL).

Constantina

A question for clarification, if the DB structure is there, why would db:migrate fail and report a missing column? – Burschenschaft

My guess is that there is an issue with either the database files or with the migration history. Sometimes I'll be writing a migration, run it, change my mind, alter the migration, and rerun it. However, I might not get the up/down migration working as perfect reverses. Or, some migration might fail halfway through and leave the DB in a partially migrated state. Or, a colleague might have migration 20151027 that changes columns, but 20151026 removes them and happens to get deployed first. When the two branches get merged stuff could break. – Constantina

Answer 2

If you start a new rails/spree project with sqlite3 on your machine (let's call it machine A) and your friend wants to use the same code on machine B you have to keep some things in mind:

The .sqlite3-files stored under db/ are automatically added to .gitignore file by the rails generator.

...  
# Ignore the default SQLite database.
/db/*.sqlite3
/db/*.sqlite3-journal
...

So your friend doesn't even get the database, if you didn't change .gitignore (which I don't recommend, because when deploying you don't not want to have the development stuff on your production server)

The workflow should be:

• You develop an machine A
• You commit/push changes
• Your friend pulls changes
• Your friend calls rake db:migrate every time he pulled the repo.
• (optionally) you populate db/seeds.rb with sample data and call rake db:seed
• when he pushes you can do steps 1-4 to have your database setup correctly

Hope this helps understanding

Rakehell