Add code lens for running migrations

[gmcgibbon]

Closes #51

Adds code lens to run migrations to specific versions in the terminal. This is convenient because it allows developers to quickly rollback or fast-forward to specific schema versions with a click.

[vinistock]

This is great! Thanks for contributing it.

Since the LSP specification doesn't allow us to add more details to a code lens (all we have is the button label), I'm trying to think about how we can communicate the action that will occur as clearly as possible.

For example, I can see someone clicking on the Run in terminal button in an old migration and being confused as to why it didn't run their latest migrations (just bin/rails db:migrate).

I have a couple of questions so that we can converge on the DX:

• Is there a difference between migrating using the latest migration version and simply running db:migrate to run all of them? I mean the end result of doing each action
• Is there a different between migrating to a specific version vs rolling back to that version? For example, is migrating to the second to last version exactly the same as db:rollback?

What I'm trying to figure out is:

• Do we need to change the button to Migrate to this version instead of Run in terminal?
• Do we need to add Run all migrations and Rollback latest migration buttons?

Basically, the addition of the extra code lens would assist us in communicating to the developer that there's a difference between running all migrations and migrating to a specific version, which should help prevent confusion.

[andyw8]

Is there a different between migrating to a specific version vs rolling back to that version? For example, is migrating to the second to last version exactly the same as db:rollback?

I noticed this in the docs:

Neither of these rails commands do anything you could not do with db:migrate. They are there for convenience, since you do not need to explicitly specify the version to migrate to.

[vinistock]

Thanks for sharing. Do people agree with using 3 code lenses?

Run all migrations | Migrate to this version | Rollback latest migration

I feel like usually people want to run bin/rails db:migrate and bin/rails db:rollback. Having those there will be handy, but it will also help communicate that Migrate to this version may actually be rolling back their database.

[gmcgibbon]

Seems like my PRs are getting stale. I'll see if I can find some time to rebase and stuff the logic into different listeners.

[gmcgibbon]

Do people agree with using 3 code lenses?

Personally I would be supportive of this order: Migrate to this version | Run all migrations | Rollback latest migration. Idiomatically, if we're putting these lenses on all migrations, the developer would open the migration they want to go to. I would go as far as to say the other lenses should only be visible on the latest migration.

Is there a difference between migrating using the latest migration version and simply running db:migrate to run all of them? I mean the end result of doing each action

Andy is correct, VERSION=<latest> and no args to run all are the same.

Is there a different between migrating to a specific version vs rolling back to that version? For example, is migrating to the second to last version exactly the same as db:rollback?

Yes, I think so. Rollbacks can specify a step count though, so that's slightly different. The default step is one, but you can do something like bin/rails db:rollback STEP=3.

It is just really convenient to use the VERSION for my use-case because Rails can figure out if I mean I want to go up or down, and by how many steps.

[vinistock]

What if we go with a single code lens, but that says Migrate to this version (2 versions behind latest)?

I believe that would provide the full context and avoid needing multiple buttons.

[vinistock]

We can definitely remove this. This is the only class that should be using this constant.

[vinistock]

Does the command in the VS Code extension need the location information? If it's just using the command to run the migration, then we can remove the location information here and just return command.

[vinistock]

On second thought, I think we may be over optimizing this too early. Figuring out how many migrations behind the current one is from the latest will require listing files and consume time in IO.

How about we ship this with only Migrate to this version and gather feedback?