Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Environment-Specific Migrations Made Easy (for test data) #536

Closed
inadarei opened this Issue Jan 18, 2018 · 2 comments

Comments

Projects
None yet
1 participant
@inadarei
Copy link

inadarei commented Jan 18, 2018

I'm submitting a...


[ ] Bug report  
[x] Feature request

Current behavior

If you wanted to write a migration that only runs in certain environment(s), currently you would have to implement it in Javascript by analyzing db.internals.argv.env in exports.up. If many of your migrations are environment-specific this can get tedious and error-prone.

An important use-case where you may want to run some migrations in certain environments and not in others is the case of test data. It is extremely useful if your migrations can set up appropriate test data for:

  1. integration tests
  2. user-acceptance tests in QA environment
  3. development environments so that devs don't code against empty data.
    etc.

Expected behavior

Configuring environmental context of a migration should require no coding and be descriptive, via configuration.

For instance, in configuration you should be able to indicate something along the lines of:

{
  "dev": {
    "driver": "sqlite3",
    "filename": "~/dev.db"
  },

  "test": {
    "driver": "sqlite3",
    "filename": ":memory:"
  },

  "prod": {
    "driver": "mysql",
    "user": "root",
    "password": "root",
    "skip_migrations" : [
     "20171128161750-insert-dummy-users.js",
     "20171221211431-insert-dummy-products.js", 
    ]
  },

}

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Supporting test data for applications in an easy and elegant way, via migrations.

Environment


db-migrate version: X.Y.Z
plugins with versions: X.Y.Z
db-migrate driver with versions: 

Additional information:
- Node version: XX  
- Platform:  

Others:

@inadarei inadarei changed the title Environment-Specific Migrations Made Easy Environment-Specific Migrations Made Easy (for test data) Jan 18, 2018

@inadarei

This comment has been minimized.

Copy link
Author

inadarei commented Jan 22, 2018

Here is an example of code that you would need to write today to achieve the desired effect:

exports.up = function(db) {
  var filePath = path.join(__dirname, 'sqls', '20171120013239-sample-user-data-up.sql');
  if (db.internals.argv.env !== "dev" && db.internals.argv.env !== "cicd" ) {
    console.log("Environment is not 'dev'. Skipping " + filePath);
    return new Promise( function( resolve, reject ) { resolve(""); });
  }
// ... rest of the up function
}

exports.down = function(db) {
  var filePath = path.join(__dirname, 'sqls', '20171120013239-sample-user-data-down.sql');
  if (db.internals.argv.env !== "dev" && db.internals.argv.env !== "cicd" ) {
    console.log("Environment is not 'dev'. Skipping " + filePath);
    return new Promise( function( resolve, reject ) { resolve(""); });
  }
// ... rest of the down function
}

It is significantly more cumbersome and error-prone than the configuration-based approach suggested in the ticket, no?

@stale

This comment has been minimized.

Copy link

stale bot commented Feb 21, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Feb 21, 2018

@stale stale bot closed this Feb 28, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.