Consider using `Promise.using` syntax for transactions

From your example, doing this:

var Promise = require(‘bluebird’);

knex.transaction(function(t) {

  knex('books')
    .transacting(t)
    .insert({name: 'Old Books'})
    .then(function(row) {

      return Promise.all(_.map([
        {title: 'Canterbury Tales'},
        {title: 'Moby Dick'},
        {title: 'Hamlet'}
      ], function(info) {

        info.row_id = row.id;

        // Some validation could take place here.
        return knex('book').transacting(t).insert(info);

      }));
    })
    .then(t.commit, t.rollback);

}).then(function() {
  console.log('3 new books saved.');
}, function() {
  console.log('Error saving the books.');
});

var Promise = require(‘bluebird’);

Can become this:

knex.transaction(function(t) {
  return knex('books')
    .transacting(t)
    .insert({name: 'Old Books'})
    .then(function(row) {
       return Promise.all(_.map([
         {title: 'Canterbury Tales'},
         {title: 'Moby Dick'},
         {title: 'Hamlet'}
        ], function(info) {
        info.row_id = row.id;
        // Some validation could take place here.
        return knex('book').transacting(t).insert(info);
      }));
    });
}).then(function() { // this happens if the above promise resolved.
  console.log('3 new books saved.');
}, function() { // this happens if the promise returned from the transaction rejected
  console.log('Error saving the books.');
});

See https://github.com/petkaantonov/bluebird/blob/iterators/API.md#resource-management

Even the transacting(t) part could be removed here, you can also use .bind to set the this value to the transaction.

[paynecodes]

I’ve been surfing the net for some good information on how to write mocha tests that will rollback changes in each test when the test completes. I can see from some of the examples above and from #263 how this might be done when using knex directly in tests.

I’m wondering, though, if anyone can offer up a best practice for rolling back changes to the database when doing other types of tests such as http request tests. Assume there aren’t always appropriate http methods available on a resource to delete/rollback, and this should be handled automatically/transparently by the test runner.

A few considerations:

1. Figure out a way to use begin and rollback mentioned here.
2. Call bookshelf.knex.raw('truncate table ' + tableName + ' cascade'); before each test, and stand up some test related seed data once this completes.
3. EDIT Use a Template Database to CREATE and new db after DROPing the temporary test database.

Any other thoughts or suggestions?

[andrewvc]

I’d like to add that I think this makes a ton of sense. Especially the ‘bind’ part. I’m currently working on a ‘begin; rollback’ database cleaning strategy for my tests (I’m using postgres, where this is sane), which means I have to wrap all the queries and transactions in a single test in a larger transaction, then roll it back. It’s a fast and foolproof way of cleaning up between tests.

The current syntax makes this unduly hard!