dogweather
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_migrationsthat 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"
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Build Elixir applications with speed and confidence.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixir-ls
- #ai
- #elixirconf-us
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
cschmatzler
Not sure about Rails, but what’s the issue you’ve run in with Ecto?
LostKobrakai
Seems like there are already a few paths:
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.
trisolaran
Ecto.Migrator.up accepts a
prefixoption with which you can specify a schema. Theschema_migrationstable 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