Managing database changes between a Rails and Java project

Question

At a new job I started, we have both a Java application that handles most of the heavy lifting in the core business logic, and we also have a Rails application that of course handles the web interface to this server. Both of these access the same database.

Up until now, most of the focus has been on the Java application, and as such, there are no migrations in the Rails project. The sql to update the shared database is managed in a file like changes.sql.

As you can imagine, this makes it somewhat difficult to develop.

My initial thought was to combine the codebases for the Java project and the Rails application, because there is a dependency there, and to manage that SQL file in the source. However, I thought I'd ask here to see if anyone else had tackled this issue with some degree of success.

Answer 1

One approach is to use the rails migration tools, generate the DDL files for the database and use Hibernate to update the Java objects that relate to specific database entities. You don't really say how you manage database changes on the Java side or whether you use an ORM, but you can certainly synchronize the two with a little work.

Or you can go the other way around and let the Java definitions control changes on the Rails side.

I think the key to doing this successfully is to select one of the two platforms as your "primary database modeller" and develop the process to migrate that model to the other platform. Attempting to allow changes from both will only cause headaches.

Answer 2

Thanks Steve

On the Java side, they are using Hibernate, but with a manual SQL updating process.

I agree, that it should be one or the other. The more I think about it, adding yet another application / module / codebase to manage just the database is definitely the wrong idea.

Thanks

Answer 3

We have a similar project structure: shared database with both java and rails applications as clients. I advocated and got buy-in to use the rails migration mechanism for handling database changes. It takes a bit of rails advocacy, and some willingness to help but the java team is also writing their own migrations.

We have some cases where we use stored procedures and database specific column types, so we changed the rails environment.rb to use sql for creating the test database.

  # Use SQL instead of Active Record's schema dumper when creating the test database.
  # This is necessary if your schema can't be completely dumped by the schema dumper,
  # like if you have constraints or database-specific column types
  config.active_record.schema_format = :sql

On the plus side managing the sql with migrations makes rails testing and setup clean for you. The downside is that some of the migration files are just not that pretty (e.g., you can't use the migration DSL to generate stored procedures so you have these execute %{blah } in your migrations).

Just remember to keep communication lines open beteen the teams. I like the fact that "cap production deploy:migrations" makes updating the production database dead simple.