Configurable migration table name

[ThomWright]

The fixed migration table name is a bit meh, would be useful to configure it.

Would it be useful to be able to specify a schema for the migration table?

@rafakato

[rafakato]

It's something that takes no time to implement, but will need to implement a custom insert function or only allow to add more fields to the current schema, and for me personally I don't think it's necessary.

@ThomWright

[rafakato]

Within the changes to implement custom migration table name, I'll also do:

• support to schema name
• support to connection uri;
• normalize modules exports (I was reading this article and even that import/export is not used we still get the refactoring benefit);

[boblauer]

I have the need for a configurable migration table, as I want to run migrations from several different applications against the same database, and so I'll have multiple files with the same index (e.g. app1/migrations/1-app1-stuff.sql and app2/migrations/1-app2-stuff).

I'm happy to open a pull req, but am having trouble understanding this sentence from above:

but will need to implement a custom insert function or only allow to add more fields to the current schema

My thinking is that this task would require two updates:

1. Update the hard-coded migration table name variable at https://github.com/ThomWright/postgres-migrations/blob/master/src/migrate.js#L33 to read in a config value, and default to "migrations".

2. Update https://github.com/ThomWright/postgres-migrations/blob/master/src/migrations/0_create-migrations-table.sql to include the dynamic table name.

Does this approach sound correct?

[rafakato]

Hi @boblauer, I've read your PR and did one implementation using js file to try to avoid the problem you cite with hash. #13

[ThomWright]

@boblauer Before I have a look at the PR I'd like to get a better understanding of your use case, to make sure this is the best solution to the problem.

Specifically I'm interested in:

I want to run migrations from several different applications against the same database

Something doesn't feel right about this to me. Could you explain a bit more about why things are set up this way, rather than each application having its own database?

The problem I see is that each application could be trying to migrate the same database in different directions, and they could all have inconsistent views on what the current state is.

[boblauer]

Sure thing. These smaller applications make up a larger ecosystem, for lack of a better word. So they all share a few common tables, such as user, but they also have their own tables specific to their functionality.

Each app will only modify the tables that it is responsible for. In other words, if the app wasn't responsible for creating the table, it will never make updates to the table.

[ThomWright]

This sounds like a microservice architecture where the services are using the database as their integration point.

This is generally considered an anti-pattern, and not something I want to support.

Here are some resources to learn more about this:

• https://www.martinfowler.com/bliki/IntegrationDatabase.html
• http://microservices.io/patterns/data/shared-database.html

If you are working on a microservices-style system, I'd also recommend Building Microservices by Sam Newman.

Admittedly I don't know anything about your application or use-case, but I would advise keeping the services separate, with their own databases. If several of them need access to e.g. user data, they should communicate with each other or duplicate the data.