mirror of
https://github.com/clockworklabs/SpacetimeDB.git
synced 2026-05-18 05:32:41 -04:00
Tyler Cloutier
9e3ffeb932
# Description of Changes This PR modifies the `--delete-data` flag on `spacetime publish` and adds the `--delete-data` flag on `spacetime dev`. In particular instead of `--delete-data` being a boolean, it is now a an enum: - `always` -> corresponds to the old value of `true` - `never` -> corresponds to the old value of `false` - `on-conflict` -> clears the database, but only if publishing would have required a manual migration This flag does NOT change any behavior about prompting users to confirm if they want to delete the data. Users will still be prompted to confirm UNLESS they pass the separate `--yes` flag. `spacetime dev` gets the same `--delete-data` flag. The default value of `never` is equivalent to the existing behavior. `spacetime dev` continues to publish with `--yes` just as before. This behavior is unchanged. # API and ABI breaking changes Adds the flags specified above. This is NOT a breaking change to the CLI. Passing `--delete-data` is the equivalent of `--delete-data=always`. This IS technically a breaking change to the `pre_publish` route. As far as I'm aware this is *only* used by our CLI however. > IMPORTANT SIDE NOTE: I would argue that `--break-clients` should really be renamed to `--yes-break-clients` because it actually behaves like the `--yes` force flag, but only for a subset of the user prompts. I have not made this change because it would be a breaking change, but if the reviewers agree, I will make this change. # Expected complexity level and risk 2, Very small change, but if we get it wrong users could accidentally lose data. I would ask reviewers to think about ways that users might accidentally pass `--delete-data --yes`. # Testing - [ ] I have not yet tested manually. --------- Signed-off-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com> Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com> Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com> Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com>
64 lines
2.0 KiB
Rust
64 lines
2.0 KiB
Rust
use clap::ArgAction::SetTrue;
|
|
use clap::{value_parser, Arg, ValueEnum};
|
|
|
|
#[derive(Copy, Clone, Debug, ValueEnum, PartialEq)]
|
|
pub enum ClearMode {
|
|
Always, // parses as "always"
|
|
OnConflict, // parses as "on-conflict"
|
|
Never, // parses as "never"
|
|
}
|
|
|
|
pub fn server() -> Arg {
|
|
Arg::new("server")
|
|
.long("server")
|
|
.short('s')
|
|
.help("The nickname, host name or URL of the server")
|
|
}
|
|
|
|
pub fn identity() -> Arg {
|
|
Arg::new("identity")
|
|
.long("identity")
|
|
.short('i')
|
|
.help("The identity to use")
|
|
}
|
|
|
|
pub fn anonymous() -> Arg {
|
|
Arg::new("anon_identity")
|
|
.long("anonymous")
|
|
.action(SetTrue)
|
|
.help("Perform this action with an anonymous identity")
|
|
}
|
|
|
|
pub fn yes() -> Arg {
|
|
Arg::new("force")
|
|
.long("yes")
|
|
.short('y')
|
|
.action(SetTrue)
|
|
.help("Run non-interactively wherever possible. This will answer \"yes\" to almost all prompts, but will sometimes answer \"no\" to preserve non-interactivity (e.g. when prompting whether to log in with spacetimedb.com).")
|
|
}
|
|
|
|
pub fn confirmed() -> Arg {
|
|
Arg::new("confirmed")
|
|
.required(false)
|
|
.long("confirmed")
|
|
.action(SetTrue)
|
|
.help("Instruct the server to deliver only updates of confirmed transactions")
|
|
}
|
|
|
|
pub fn clear_database() -> Arg {
|
|
Arg::new("clear-database")
|
|
.long("delete-data")
|
|
.alias("clear-database")
|
|
.short('c')
|
|
.num_args(0..=1)
|
|
.value_parser(value_parser!(ClearMode))
|
|
// Because we have a default value for this flag, invocations can be ambiguous between
|
|
//passing a value to this flag, vs using the default value and passing an anonymous arg
|
|
// to the rest of the command. Adding `require_equals` resolves this ambiguity.
|
|
.require_equals(true)
|
|
.default_missing_value("always")
|
|
.help(
|
|
"When publishing to an existing database identity, first DESTROY all data associated with the module. With 'on-conflict': only when breaking schema changes occur."
|
|
)
|
|
}
|