stepdown non-functional

[jdavisclark]

per @soitgoes, step down may be broken in some instances when things are in a dirty state

[jdavisclark]

steps to reproduce:

1. create a migration or two and execute them
2. delete the last executed migration from disk (probably breaks if you delete any of them)

status thinks things are dirty now. stepdown doesn't actually do anything but reports success.

Solutions

1. add mite doctor or mite cleanup, which cleans up the state if tracked migrations are missing from disk (would assume that the disk migrations are accurate). this would not actually step up/down; it would only remove tracked migrations that are no longer on disk.
2. make mite stepdown and mite down throw a confirmation warning if they encounter this, and allow them to step past (essentially performing the same cleanup as above) if confirmed.

[soitgoes]

In order to do the most cool thing and repair silently then we would need
to have the migration stored in the database. (Anything else would throw
off the consistency of the database, which could get difficult to repair).

Maybe the right answer is to put the migration in the database so that we
could silently do the right thing.

On Sun, Mar 22, 2015 at 4:34 PM, Davis Clark notifications@github.com
wrote:

steps to reproduce:

1. create a migration or two and execute them
2. delete the last executed migration from disk (probably breaks if
   you delete any of them)

status thinks things are dirty now. stepdown doesn't actually do anything
but reports success.

Solutions

add mite doctor or mite cleanup, which cleans up the state if tracked
migrations are missing from disk (would assume that the disk migrations are
accurate). this would not actually step up/down; it would only remove
tracked migrations that are no longer on disk.
2.

make mite stepdown and mite down throw a confirmation warning if they
encounter this, and allow them to step past (essentially performing the
same cleanup as above) if confirmed.

Reply to this email directly or view it on GitHub
#62 (comment).

Martin Murphy
Whiteboard-IT
http://whiteboard-it.com
w: (205) 588-7102

[jdavisclark]

it probably shouldn't handle it completely silently. Something had to have gone wrong for things to get in this state, so at least some type of confirmation or extra resolution step should probably happen. I kind of like the idea of storing the migration; that ensures that we could always revert migrations.

This brings us back to an issue we had a while ago where, ironically enough, we don't have a good way to do self-hosted migrations on the _migrations table... So this might be a major version bump for now.

[soitgoes]

The new use case I'm interested in is being able to check out a version of
the code base and migrate to that version matching the filesystem without
much fuss (one command).

This isn't intended to be a production command so I'm not sure it should
warn maybe just require a -f.
On Mar 22, 2015 6:11 PM, "Davis Clark" notifications@github.com wrote:

it probably shouldn't handle it completely silently. Something had to have
gone wrong for things to get in this state, so at least some type of
confirmation or extra resolution step should probably happen. I kind of
like the idea of storing the migration; that ensures that we could
always revert migrations. Though about doing it a while ago just in
case we ever needed it...

This brings us back to an issue we had a while ago where, ironically
enough, we don't have a good way to do self-hosted migrations on the
_migrations table... So this might be a major version bump for now.

Reply to this email directly or view it on GitHub
#62 (comment).

[jdavisclark]

so I'm not sure it should warn maybe just require a -f.

Thats what I was thinking. more than adequate.