Closed JamesMGreene closed 9 years ago
Hey @JamesMGreene , thanks for your suggestion. In the interest of keeping this package as light as possible I'm going to refrain from making this change as it's reasonably trivial to work around it.
Just so we're on the same page, the change I'm proposing would just be:
migration[direction].call();
migration[direction].call(null, migration);
OR:
migration[direction].call(migration, migration);
Not exactly heavy. :wink:
Yeah ok, on second thoughts that's reasonable. I'd accept a PR, I think we can leave the parameter undocumented though.
@zol: PR #35 submitted.
I would like to see a context object (probably the whole
migration
object, honestly) provided as an argument to the invocation ofup
anddown
.This can be beneficial for several reasons:
To avoid copy/paste errors
down
function that made it asymmetrical with theup
function: a query field value that was not updated.data
(or some other name) property to be added onto the Migration object [alongside the existingname
/version
/up
/down
properties], which would then be included as an argument (or sub-argument) to the actual invocations of theup
anddown
functions.For logging purposes. Example:
For auditing purposes. Example:
For manual error handling purposes IF AND ONLY IF you know your
up
ANDdown
are 100% symmetrically recoverable (although this is also a per-Migration option I'd like to see implemented separately in this package... but I'll open a separate issue for that). Example: