Implement custom migration table name

[djgrant]

This enables users to pass their own migration table name.

Migrate can now be called like:

await migrate(dbConfig, "path/to/migration/files", {
  migrationTableName: "schema.my_migrations",
})

I didn't manage to get the tests running locally so they may need looking at.

Let me know if you want any changes!

[djgrant]

I changed to to_reclass as the original query would check if a table name exists in any schema. This meant migrations would broke in the case that a user specifies a schema in migrationTableName.

[ThomWright]

Have you looked through the existing issues/PRs around this?

Search: https://github.com/ThomWright/postgres-migrations/issues?q=migration+table+name

• Search for the migrations table in the correct schema #41
• Check schema when checking for migrations table. #34
• Make doesTableExist check for table in current search path #33
• Implementing configurable migrations table name #13
• Config migration table name #12
• Configurable migration table name #4

Does this solve the problem of the initial migration hash changing, which is a breaking change for anyone using this library?

And does it work for existing users who have access to the public schema revoked? #33

[djgrant]

Published as https://www.npmjs.com/package/@djgrant/postgres-migrations/v/4.1.0-rc.0

[djgrant]

Hey @ThomWright, thanks for taking a look at this! I've added a solution for the initial migration hashing problem. It's an awkward problem - I've done the best I can with it.

My feeling is that because that migration is essentially a unique value distributed across users' DBs it makes sense to almost hardcode it. I've moved all the code for creating the initial migration into one module to hopefully make this all a bit more explicit - and be clear that the initial migration is the only migration the library will ever produce itself. I've also added a regression test to make sure that future versions don't break the initial migration.

On #33, I'd need to look into this in more detail another time. Unless you have a solution in mind already?

Published changes as https://www.npmjs.com/package/@djgrant/postgres-migrations/v/4.1.0-rc.1

[djgrant]

Worth mentioning that with this implementation a user who changes the location of their migrations table will not be able to simply move the old migrations table.

[djgrant]

Does this test satisfy what you were asking for in #33 (comment)?

[djgrant]

@ThomWright, did you have any thoughts on this? Happy to close if you don't feel it's the right solution for the library but equally can make changes to get it where you want.

Personally, I'm just relying on the change that allows me to run migrations in a different schema (using SET search_path TO schema_name). I wonder if that would cover most use cases and priority should be given to #33.

[ThomWright]

Hi @djgrant - sorry for the delay. I just haven't had the time/energy to give this proper focus. I noticed you published your own version, are you OK just using that for now? Hopefully I'll get around to this another time.

[djgrant]

Yes, of course – that's what's forking is for after all! Just wanted to check before I switch focus.