Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: riverpro missing line type workflows -> workflow #546

Closed
krhubert opened this issue Aug 22, 2024 · 3 comments
Closed

docs: riverpro missing line type workflows -> workflow #546

krhubert opened this issue Aug 22, 2024 · 3 comments

Comments

@krhubert
Copy link

Hi,

When I run cli with --line workflows it panics.

riverpro migrate-up --database-url  "postgres://postgres:@localhost:5432/postgres" --line workflows
panic: migration line does not exist: workflows

But with --line workflow all is good

riverpro migrate-up --database-url  "postgres://postgres:@localhost:5432/postgres" --line workflow

Links with typos

https://riverqueue.com/docs/pro/go-proxy#installing-in-ci-and-build-environments
https://riverqueue.com/docs/pro/getting-started#running-pro-migrations

@brandur
Copy link
Contributor

brandur commented Aug 22, 2024

Thanks Hubert!

Wow, believe it or not, we've had multiple people run through those steps already, but you're the first to report the problem to us :/

I just pushed a fix. We should really also have some basic Levenshtein distance check that'd be able to detect a one letter difference and suggest a correction too. I'll look into that separately.

Please don't hesitate to open any more bug reports if you find other problems!

@brandur brandur closed this as completed Aug 22, 2024
@krhubert
Copy link
Author

Sure, I was quite surprised that nobody ran into trouble with this one. Awesome it is fixed so fast. I'll open issues as they raise. I actually have one more already.

brandur added a commit that referenced this issue Aug 23, 2024
…ein distance

This is related to #546. That was a documentation problem, but there are
some code problems that are related.

The first is that an unknown migration line is a panic in the CLI. This
is a byproduct of the fact that `rivermigrate.New` checks the migration
line name, but doesn't return an error, so it'd panic instead.

Here, I'm suggesting that we do a small breaking change by having
`rivermigrate.New` return a possible error. It's not great, but it's
something that'll easy for people to fix, and might help avoid some
future panics. An alternative possibility would be to add a new
`NewWithError` or something of that nature, but it'd make the API a
little uglier.

Along with that change, we also bring in a change to suggest migration
lines in case of an unknown one using Levenshtein distances. This is
aimed at preventing totally unactionable errors in the event of very
simple misspellings (e.g. "workflow" versus "workflows"). Cobra actually
already has a similar feature built-in for command misspellings.

I vendored in this repo [1] as a Levenshtein implementation and did a
little code clean up. I don't want to add another Go module dependency
for such a simple algorithm (it's just a dozen lines), and I believe
their MIT license should be compatible.

[1] https://github.com/agnivade/levenshtein/tree/master
@brandur
Copy link
Contributor

brandur commented Aug 23, 2024

Going to try and do one other small follow up here to suggest alternatives when a migration line is found to be non-existent in #558.

brandur added a commit that referenced this issue Aug 23, 2024
…ein distance

This is related to #546. That was a documentation problem, but there are
some code problems that are related.

The first is that an unknown migration line is a panic in the CLI. This
is a byproduct of the fact that `rivermigrate.New` checks the migration
line name, but doesn't return an error, so it'd panic instead.

Here, I'm suggesting that we do a small breaking change by having
`rivermigrate.New` return a possible error. It's not great, but it's
something that'll easy for people to fix, and might help avoid some
future panics. An alternative possibility would be to add a new
`NewWithError` or something of that nature, but it'd make the API a
little uglier.

Along with that change, we also bring in a change to suggest migration
lines in case of an unknown one using Levenshtein distances. This is
aimed at preventing totally unactionable errors in the event of very
simple misspellings (e.g. "workflow" versus "workflows"). Cobra actually
already has a similar feature built-in for command misspellings.

I vendored in this repo [1] as a Levenshtein implementation and did a
little code clean up. I don't want to add another Go module dependency
for such a simple algorithm (it's just a dozen lines), and I believe
their MIT license should be compatible.

[1] https://github.com/agnivade/levenshtein/tree/master
brandur added a commit that referenced this issue Aug 23, 2024
…ein distance

This is related to #546. That was a documentation problem, but there are
some code problems that are related.

The first is that an unknown migration line is a panic in the CLI. This
is a byproduct of the fact that `rivermigrate.New` checks the migration
line name, but doesn't return an error, so it'd panic instead.

Here, I'm suggesting that we do a small breaking change by having
`rivermigrate.New` return a possible error. It's not great, but it's
something that'll easy for people to fix, and might help avoid some
future panics. An alternative possibility would be to add a new
`NewWithError` or something of that nature, but it'd make the API a
little uglier.

Along with that change, we also bring in a change to suggest migration
lines in case of an unknown one using Levenshtein distances. This is
aimed at preventing totally unactionable errors in the event of very
simple misspellings (e.g. "workflow" versus "workflows"). Cobra actually
already has a similar feature built-in for command misspellings.

I vendored in this repo [1] as a Levenshtein implementation and did a
little code clean up. I don't want to add another Go module dependency
for such a simple algorithm (it's just a dozen lines), and I believe
their MIT license should be compatible.

[1] https://github.com/agnivade/levenshtein/tree/master
brandur added a commit that referenced this issue Aug 23, 2024
…ein distance

This is related to #546. That was a documentation problem, but there are
some code problems that are related.

The first is that an unknown migration line is a panic in the CLI. This
is a byproduct of the fact that `rivermigrate.New` checks the migration
line name, but doesn't return an error, so it'd panic instead.

Here, I'm suggesting that we do a small breaking change by having
`rivermigrate.New` return a possible error. It's not great, but it's
something that'll easy for people to fix, and might help avoid some
future panics. An alternative possibility would be to add a new
`NewWithError` or something of that nature, but it'd make the API a
little uglier.

Along with that change, we also bring in a change to suggest migration
lines in case of an unknown one using Levenshtein distances. This is
aimed at preventing totally unactionable errors in the event of very
simple misspellings (e.g. "workflow" versus "workflows"). Cobra actually
already has a similar feature built-in for command misspellings.

I vendored in this repo [1] as a Levenshtein implementation and did a
little code clean up. I don't want to add another Go module dependency
for such a simple algorithm (it's just a dozen lines), and I believe
their MIT license should be compatible.

[1] https://github.com/agnivade/levenshtein/tree/master
brandur added a commit that referenced this issue Aug 24, 2024
…ein distance

This is related to #546. That was a documentation problem, but there are
some code problems that are related.

The first is that an unknown migration line is a panic in the CLI. This
is a byproduct of the fact that `rivermigrate.New` checks the migration
line name, but doesn't return an error, so it'd panic instead.

Here, I'm suggesting that we do a small breaking change by having
`rivermigrate.New` return a possible error. It's not great, but it's
something that'll easy for people to fix, and might help avoid some
future panics. An alternative possibility would be to add a new
`NewWithError` or something of that nature, but it'd make the API a
little uglier.

Along with that change, we also bring in a change to suggest migration
lines in case of an unknown one using Levenshtein distances. This is
aimed at preventing totally unactionable errors in the event of very
simple misspellings (e.g. "workflow" versus "workflows"). Cobra actually
already has a similar feature built-in for command misspellings.

I vendored in this repo [1] as a Levenshtein implementation and did a
little code clean up. I don't want to add another Go module dependency
for such a simple algorithm (it's just a dozen lines), and I believe
their MIT license should be compatible.

[1] https://github.com/agnivade/levenshtein/tree/master
brandur added a commit that referenced this issue Aug 24, 2024
…ein distance

This is related to #546. That was a documentation problem, but there are
some code problems that are related.

The first is that an unknown migration line is a panic in the CLI. This
is a byproduct of the fact that `rivermigrate.New` checks the migration
line name, but doesn't return an error, so it'd panic instead.

Here, I'm suggesting that we do a small breaking change by having
`rivermigrate.New` return a possible error. It's not great, but it's
something that'll easy for people to fix, and might help avoid some
future panics. An alternative possibility would be to add a new
`NewWithError` or something of that nature, but it'd make the API a
little uglier.

Along with that change, we also bring in a change to suggest migration
lines in case of an unknown one using Levenshtein distances. This is
aimed at preventing totally unactionable errors in the event of very
simple misspellings (e.g. "workflow" versus "workflows"). Cobra actually
already has a similar feature built-in for command misspellings.

I vendored in this repo [1] as a Levenshtein implementation and did a
little code clean up. I don't want to add another Go module dependency
for such a simple algorithm (it's just a dozen lines), and I believe
their MIT license should be compatible.

[1] https://github.com/agnivade/levenshtein/tree/master
brandur added a commit that referenced this issue Aug 24, 2024
…ein distance (#558)

This is related to #546. That was a documentation problem, but there are
some code problems that are related.

The first is that an unknown migration line is a panic in the CLI. This
is a byproduct of the fact that `rivermigrate.New` checks the migration
line name, but doesn't return an error, so it'd panic instead.

Here, I'm suggesting that we do a small breaking change by having
`rivermigrate.New` return a possible error. It's not great, but it's
something that'll easy for people to fix, and might help avoid some
future panics. An alternative possibility would be to add a new
`NewWithError` or something of that nature, but it'd make the API a
little uglier.

Along with that change, we also bring in a change to suggest migration
lines in case of an unknown one using Levenshtein distances. This is
aimed at preventing totally unactionable errors in the event of very
simple misspellings (e.g. "workflow" versus "workflows"). Cobra actually
already has a similar feature built-in for command misspellings.

I vendored in this repo [1] as a Levenshtein implementation and did a
little code clean up. I don't want to add another Go module dependency
for such a simple algorithm (it's just a dozen lines), and I believe
their MIT license should be compatible.

[1] https://github.com/agnivade/levenshtein/tree/master
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants