Coexisting with a Rails database

I’m making a simple Phoenix app to manage links to news. The articles relate to data in a Rails app. I’d like for the Phoenix tables to live alongside Rails tables in the same Postgres database and schema. The Phoenix app would get read-only access to the Rails tables, and vice-versa.

I’ve run into a couple of roadbumps:

  • Both Rails and Phoenix use a table, schema_migrations. But the tables’ structures as created by the frameworks are different.
  • Keeping everything in the same schema seems less problematic: both frameworks don’t work so well with multi-schema queries.

So, I wonder:

  • Is it possible to customize the name of schema_migrations that Phoenix maintains?
  • Or, if Phoenix needs its own Postrgres schema so that it can have its own schema_migrations, then how does the multi-schema story look currently?

Is there another solution I don’t know about?

EDIT: I found that Rails allows the table name to be changed. This is probably all I need:

3.8.5 config.active_record.schema_migrations_table_name

Lets you set a string to be used as the name of the schema migrations table.

EDIT 2: I found how to configure this in Phoenix:

:migration_source - Version numbers of migrations will be saved in a table named schema_migrations by default. You can configure the name of the table via:

config :app, App.Repo, migration_source: "my_migrations"

Not sure about Rails, but what’s the issue you’ve run in with Ecto?

Seems like there are already a few paths:

  • Renaming the migrations table
  • Ecto afaik supports custom schemas quite well

Though I’d also argue that you shouldn’t really have two migration systems run against the same db. Keep things either in rails (or in phoenix I guess) or move to an external to both migration system. Even more as the phoenix one should run with a read only user, which won’t be allowed to migrate anything on that db.

5 Likes

Ecto.Migrator.up accepts a prefix option with which you can specify a schema. The schema_migrations table will be created in that schema. From the CLI: mix ecto.migrate --prefix prefix_name.

In the past 2 years I’ve been working on a Phoenix app that needed to live alongside a legacy application and share its database. In order to improve separation I decided to put my app’s “private” tables in a separate schema, with their own migrations.

I don’t recall what it was like with Rails, but with Ecto I had no issues or roadblocks with the multi-schema setup :slight_smile: