** (Mix) Could not find migrations directory "apps/umbrella_app/priv/repo/migrations"
for repo App.Repo.
This may be because you are in a new project and the
migration directory has not been created yet. Creating an
empty directory at the path above will fix this error.
If you expected existing migrations to be found, please
make sure your repository has been properly configured
and the configured path exists.
I am following this thread:
I have single repo and migrations in two different umbrella apps.
Relative to where? And where in the filesystem do you run that command? Please use proper pathes here, not any obfuscations. Perhaps replace appnames with stubs, but make sure the regular umbrella structure is preserved when doing so, that we can understand what you are actually doing.
All the umbrella apps are inside the app directory. If i Provide the absolute path volumes/projects/apps/al/priv/repo/migrations it says already up. But no migrations will run.
It seems to be working after dropping the database and creating again and then running the mix migrate command for the second app which doesn’t have a repo.
But it won’t work if i run the main app migrations first and then run the migrations from the other app(which don’t have repo). It returns already_up.
Yes its working for absolute path but only if run the migrations from the second app first(which doesn’t have repo). But it gives me Already up console message if I run this after the main app migrations(which is what I need).
How are the migrations of both apps named? And can you successfully migrate the main app after the second app?
I guess the migrations table holds the name of the migration (either module or filename, I don’t know right now) and if the migrations in both apps are named the same way it thinks they are already migrated.
I haven’t worked with Elixir and a database in a long time, so this is just a wild guess.
That table is per repository as I understand it, but OP wants a single repo and migrations in different apps of the same umbrella…
Personally I’m not convinced that this was a good design choice, the application that contains the repository should be the only one tampering with the database. Everything else will get you into trouble…
Perhaps, but imagine a plugin system, each plugin wants to run its own migrations to add its own tables to the database. Perhaps ecto needs a way to have ‘named’ version columns, I.E. have the schema_migrations table have another field that defaults to the application name or so, that way each different ‘priv’ directory has it’s own migrations and can be done and undone individually.
An external system can surely manage its own tables, but imho it should do so through migration files, which are added to the migrations path of the application it’s used in (e.g. oban does implement that quite nicely). Or if it’s part of a bigger system, where installing plugins is part of the core functionality have a truely custom handling of db migrations, but I don’t see that as feature ecto should support.
If we run mix ecto.migrate. only first command executed and second ignored.
Is this the expected behaviour?
Is there any way to override it so both commands will execute?