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

setup/teardown #25

Closed
TrejGun opened this issue Sep 18, 2013 · 4 comments
Closed

setup/teardown #25

TrejGun opened this issue Sep 18, 2013 · 4 comments

Comments

@TrejGun
Copy link

TrejGun commented Sep 18, 2013

Plz, add setup/teardown functions to open/close db connection before/after couple of migrations

@timlesallen
Copy link

+1

@geekytime
Copy link

👍 - I would probably call them before and after, though.

These simple functions could also be used to alleviate the need for #29, #41, #58, as we could load our .migrate file from the DB in before, and store it in the db in after.

The internal api and the cli wouldn't be affected.

@wesleytodd
Copy link
Collaborator

I have two thoughts on this:

  1. Use the new store as implemented in the new 1.x branch. Basically store.load is called before anything else, so you could initialize your db connections in there.
  2. Expose more event hooks with cli flags like --before="path/to/before.js" and --after="after.js"

An example of number 1 would be:

var mysql = require('mysql')
module.exports = MysqlStore
MysqlStore (configString) {
  this.db = mysql.createConneciton(configString)
}

MysqlStore.prototype.load = function (fn) {
  this.db.connect(function (err) {
    if (err) return fn(err)
    // load state from mysql, or even inherit this from the FileStore, call fn when done
    fn(null, state)
  })
}

MysqlStore.prototype.safe = function (set, fn) {
  // do save stuff, but save is called after each migration, so dont close db
}

It should work, and does not require any new api in the core module. You could even set it up easily to expose a db singleton that all your running migrations could share.

Option number 2 is much more straight forward but means added api and complexity. Would love to get opinions on which way to go.

@wesleytodd
Copy link
Collaborator

Since there is a lack of activity on this, closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants