CODEWITHSUNDEEP
ruby-on-railsrubyactiverecordsinatradatabase-migration
B Seven
B Seven

Reputation: 45943

How to manage migrations when multiple apps share the same database in Ruby?

I have a Rails app and a Sinatra app, sharing the same database. The Sinatra app uses ActiveRecord.

Can I run migrations from within each app, as if they were in the same app? Will this cause any problems?

The schema.rb file in the Rails app tracks the current migration via

ActiveRecord::Schema.define(:version => 20121108154656) do

but, how does the Sinatra app know the current version the database?

Rails 3.2.2, Ruby 1.9.3.

Upvotes: 6

Views: 3951

Answers (5)

Dale
Dale

Reputation: 61

The version column in the schema_migrations table equate to the time stamp on the front of the ruby migration file example: 20130322151805_create_customers.rb So if two ore more applications are contributing to the schema_migrations table roll backs will not be possible if rails can't find the down() method (because it will not find a migration file contained in another app ie db/migrate/...)

I have a current situation that is exactly this and I have opted to have a master ActiveRecord app that manages migration and data conversions as our database evolves. Keep in mind that part of the deal is to keep models up to date as well. This has been time consuming so we are considering breaking apart the DB in to business domains and providing APIs (JSON) to query support data for another application. This way each application manages it domain and is responsible for exposing data via API.

regards.

Upvotes: 4

B Seven
B Seven

Reputation: 45943

I decided to put all migrations in the Rails app because:

  1. Since there is only one database
  2. Rails manages migrations

This has worked well.

This simplifies the system because all migrations are stored in one place. And, the Sinatra app doesn't need to know about them anyway.

Upvotes: 0

Matt
Matt

Reputation: 5398

Rails migrations store current database version in schema_migrations table in the database. So both of your apps will be able to check the current version.

The version numbers are timestamps, so there shouldn't be any problem with duplicate values, as it'll be almost impossible to generate two migrations at the exact same millisecond. So you should be fine here.

The only problem I see is that when you rollback a migration in one app, it'll set the db to the previous known version and I'm not sure if it will pick the previous one from the db (which could be from the other app), or the number from the previous migration file. You may want to test that scenario to make sure.

Upvotes: 1

Schmurfy
Schmurfy

Reputation: 1725

If you connect both applications to the same database you should be able to run migrations on it but I strongly suggest you use another option since you will almost surely hit a wall at one time or another:

  • split the database in two if possible with each application responsible for its own database /migrations.

  • have one application considered the "master" database and use another database for the data specific to the second application but make it connects to both database (each application still only apply migrations to one database)

If you need to share data between multiple applications another option is to implement a REST service in one and use it on the other, you can have a look at the grape gem for a simple way of doing so.

Edit: I realize I forgot to speak about the activerecord migration, there is no longer any "version" of the schema, what activerecord does is that it read all your migration filename, extract their identifier (the starting part) and check if they have already been applied so in theory you can run migrations from two applications on the same database provided they don't interfere. But if both migrations act on the same tables you will almost certainly run into big troubles at one point.

Upvotes: 3

Andreas
Andreas

Reputation: 348

I disagree with Schmurfy, even if his presented options are valid, its a bit of an overkill to share data through REST (granted, its pretty easy to implement with ruby / rails).

If your case is simple you could just use one database from both apps, and since you use AR in both of them you have no problems with versioning, AR takes care of that.

Also i dont know what happens if you run db:migrate from both apps simultaniously if you use a inferior dbms like mysql which does not allow DDL in a transaction, certainly nothing good..

Also it would bother me to look which app needs what column and not have the migrations in one place. You could use a shared repository to manage the migrations from both apps.

Upvotes: 2

Related Questions