Dependencies and Multiple Database Repos?

I’d like to create apps that have multiple dependencies each with their own separate database and Ecto migrations. I’d like to use path or github dependencies specified in the top-level mix.exs file, and not use an umbrella structure.

Does anyone else use this approach? How to run migrations? How to name the databases? Could this work for nested dependencies?

Thanks in advance! :slight_smile:

1 Like

I essentially do this. I have a directory of my libraries and the one project to bring them altogether, and I just use file:// to have each reference each other as needed on down the tree. I prefer this instead of umbrellas as it makes each proper containerized (and you can do something like have mix.exs use a file:// path when it exists else fall back to a hex path or github path or so).

My database is just Blah.Repo as it’s own library (lots of helpers), migrations are referenced from each manually, etc…

2 Likes

Thanks for the reply. I’ve been experimenting with “component-style” organization the past couple days and have decided that it’s a good approach. Not only can you nest ecto applications, but you can nest phoenix apps too. I found the terminology to be somewhat confusing (libraries, projects, umbrellas, applications, components, releases, supervisors, genservers) but once you grok the layout it seems nicely composable. The 1.9-style top level configuration helps a lot.

Don’t forget, it’s not bad to pass module names of other libraries into your configuration files, this makes it easy to have a library depend on another without actually depending on it, and within it’s own compilation unit and tests it makes it oh so easily trivially mocked. :slight_smile:

2 Likes

Yeah I’ve tried swapping modules at the config level and it seems to work well. Esp with modules that implement a standard behavior. Plan to use this feature to swap delivery targets for 3rd party email services.