feat!: support for rolling back migrations - #583
Conversation
|
| Project | cot |
| Branch | elijah/migrations-rollback |
| Testbed | github-ubuntu-latest |
Click to view all benchmark results
| Benchmark | Latency | Benchmark Result microseconds (µs) (Result Δ%) | Upper Boundary microseconds (µs) (Limit %) |
|---|---|---|---|
| empty_router/empty_router | 📈 view plot 🚷 view threshold | 12,572.00 µs(+71.32%)Baseline: 7,338.41 µs | 12,807.92 µs (98.16%) |
| json_api/json_api | 📈 view plot 🚷 view threshold | 1,003.30 µs(-6.89%)Baseline: 1,077.50 µs | 1,368.44 µs (73.32%) |
| nested_routers/nested_routers | 📈 view plot 🚷 view threshold | 964.20 µs(-3.97%)Baseline: 1,004.10 µs | 1,245.23 µs (77.43%) |
| single_root_route/single_root_route | 📈 view plot 🚷 view threshold | 926.74 µs(-4.18%)Baseline: 967.14 µs | 1,208.85 µs (76.66%) |
| single_root_route_burst/single_root_route_burst | 📈 view plot 🚷 view threshold | 16,289.00 µs(-6.16%)Baseline: 17,357.78 µs | 21,685.90 µs (75.11%) |
Codecov Report❌ Patch coverage is
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 1 file with indirect coverage changes 🚀 New features to boost your workflow:
|
m4tx
left a comment
There was a problem hiding this comment.
Looks like a solid start, but we need more work on this before it can be merged.
| } | ||
| } | ||
|
|
||
| struct MigrationRollback; |
There was a problem hiding this comment.
I believe a few features would make it much more useful:
- A subcommand that would list all available migrations
- A dry run mode to see which migrations would actually be rolled back
- Actual log lines being displayed.
cot-clijusteprintlns the info when executingmigration make, which I think we could replicate here.
There was a problem hiding this comment.
For a subcommand to list all available migrations, I believe we already have that in cot-cli via cot migration list and I dont think we should duplicate that in cot crate. Perhaps this is where #587 can come in handy
There was a problem hiding this comment.
Ah, fair, I forgot about this. In that case yes, I think that should suffice for now.
For the future, though, (outside of this PR) maybe it would be useful to have a separate command for listing applied and pending migrations (which would have to be implemented outside of cot-cli I believe).
There was a problem hiding this comment.
Ah, one problem with the current solution is that it really only lists the migrations found directly in the current workspace, and it ignores any migrations defined in the dependencies, because this can't really be figured out until runtime. Because of that, I think we will need a better list command in the future. But as I've mentioned, the PR is already big enough, so let's keep it for another one.
- add an app flag which defaults to the current running app
|
|
||
| use anstyle::{AnsiColor, Color, Effects, Style}; | ||
|
|
||
| #[doc(hidden)] // Not part of Cot's public API; used by the CLI. |
There was a problem hiding this comment.
I'm wondering if it would make sense to take all the #[doc(hidden)] stuff and just move it into another crate. This shouldn't happen in this PR anyway, but this is just something that maybe we should do at some point.
There was a problem hiding this comment.
Do you think the cot-core crate is a good place to move these?
There was a problem hiding this comment.
I'm not sure, the idea behind cot-core is to only contain the bare, rock-solid minimum required to serve the core functionality (so mostly just HTTP stuff) with minimal number of dependencies. I'm not sure if adding pretty printing there (which is quite a high-level functionality) belongs there. We don't necessarily need to care about this right now, though.
|
Documentation included in #622 |
m4tx
left a comment
There was a problem hiding this comment.
Please fix the last issue and then it will Look Good To Me!
|
|
||
| #[cot::test] | ||
| async fn cli_task_group_dispatches_nested_task() { | ||
| use std::sync::atomic::{AtomicBool, Ordering}; |
There was a problem hiding this comment.
I think this can be moved directly into mod tests.
| } | ||
| } | ||
|
|
||
| struct MigrationRollback; |
There was a problem hiding this comment.
Ah, one problem with the current solution is that it really only lists the migrations found directly in the current workspace, and it ignores any migrations defined in the dependencies, because this can't really be figured out until runtime. Because of that, I think we will need a better list command in the future. But as I've mentioned, the PR is already big enough, so let's keep it for another one.
Related issue or discussion
fixes #547
Description
This allows rolling back migrations to the specified migration file.
Assuming the project has the following migration files in its migration dir:
The above command will roll back(unapply) the
m_0002_secondfile, leavingm_0001_initialapplied.Alternatively, the migration file number can be used for convenience:
Migrations are currently tied to a crate(the crate name is used), which means rolling back a migration in a project that imports apps from external crates will implicitly (and only) rollback migrations in the current project/crate. This might change when support for workspaces is added.
This PR also provides a dry-run command to preview migrations to be rolled back before they actually do:
As a bonus, this PR also adds CLI Group tasks as a means to group nested related subcommands under a parent subcommand:
Eg.
Type of change