Duplicated 'migrations' table when using schemas

[EyMaddis]

When using a schema: 'mySchema' configuration in the database.json, I can run db-migrate and it will create a migrations table on the publicschema. Running the migration again leads to a secondmigrationstable inside themySchema` schema.

I would guess that this might require a better configuration possibility for the migrations schema which is currently only possible via the --table my_migrations command line argument. I would like to configure a like like myOtherSchema.my_migrations, because I don't want to mix real/customer data with technical data (migrations).

Sidenote: is it possible to configure the migration table via the database.json? I tried, but failed.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[wzrdtales]

@EyMaddis No you can't configure it via the database.json and currently you can't, but on the latest master branch there already is the rc config included which will allow you to do so via a .dbmigraterc config. About the behavior, this is really strange, can you provide me a full example to reproduce this?

[justinnguyen]

I ran into the same issue. What it ended up being for me was that my first migration script was creating the schema that I had configured in my schema field in database.json. Because this schema didn't exist until the first migration was run, the migrations table was created in the public schema the first time I ran db-migrate. On the next run, another migrations table was created in my configured schema, but because it is empty, all of my migrations are run all over again.

Bump. Completely same behavior as @justinnguyen describe. Any progress on that?

[mo]

Bump. I hit the same issue as @justinnguyen and @igorlysak hit.

[mo]

I think it would be good if db-migrate-pg just checked if the schema specified in database.json exists, and if not then it should be created before the actual migrations start.

[Kaltemrix]

Any update on when the above PR will be merged in?