Yes I migrate successfully the main app after the second app migrated but not vice versa.
script
hlx
NobbZ
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…
3
OvermindDL1
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.
1
LostKobrakai
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.
2
script
Inside the aliases in mix file. If we define migration command like this:
defp aliases do
[
"ecto.migrate": [
"ecto.migrate data/priv/repo/migrations",
"ecto.migrate --migrations-path apps/al/priv/repo/migrations"
]
]
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?
0
jerdew
In case anyone else comes across this post in search of an answer: there is a way to override it.
Mix — Mix v1.12.3 and text search for “Tasks can be executed again”
0
