autoexecute after db:migrate

[gravis]

it would be nice to run the task right after a db:migrate automatically, so user won't forget to comment the changes (if needed).
We could add an option in an initializer to disable this feature.
What do you think?

[comboy]

That's surely a good idea because in most cases that's when you want to run it.

I'm just afraid of a following scenario: I'm implementing some new feature and I have dirty working tree, including model file that is going to be updated by annotator. Now if because of some bug in annotator,or me doing some random stuff with annotator comments, annotator would somehow destroy some part of my work, I would be very very angry (I mean I would just press 'u' in vim, but anyway) . So this is not very probable, but that's why this feature is not there yet. But possibly I'm being paranoid.

We could save same .bak files in tmp dir I suppose, but I'm not sure if it's worth the effort. What do you think? Should we backup them or care in general about such very unprobable events?

[vanyak]

I think this feature might be quite useful in some cases but when adding a foreign key field for an association you would still need to run annotator after the association was defined in the model. Otherwise there will be default TODOs for the field.
Unless there is a generic way to detect if the file is open by the other application (like looking for .swp file in case of vim) and just display changes without actually applying them, this can be dangerous in some cases.

[comboy]

That's a good point @vanyak. Although as you mention these TODOs would be fixed after running it again, so it could still work as a kind of reminder.

I don't like trying to detect whether file is opened or not (btw, personally I keep .swps in non-default location). This idea with displaying some info after db:migrate may be interesting.