#[non_exhaustive]pub enum Repeatable {
Freely,
WithMutationId,
Never,
Heavy,
}Expand description
How a command may be repeated — and, for a heavy one, where it goes.
The classification is the cluster’s, not this crate’s: each command declares
whether it mutates and whether it is heavy, and the rules at the top of this
module follow from those two bits. A modelled command has its answer written
into its call site; Client::raw_command_with
is where a caller supplies one for a command this crate does not model.
Repeatable::Never is the safe answer and the default there. A retry
of something that turned out to be mutating applies it twice, and a
mutation_id only prevents that where the master’s mutation cache covers
the command — it does not cover the scheduler, which is why
Client::abort_operation is Never
despite being both light and mutating.
The enum is #[non_exhaustive]: the cluster’s registry has more shapes than
this crate has needed so far, and a caller that matches on it exhaustively
would break the next time one of them earns a name.
Variants (Non-exhaustive)§
This enum is marked as non-exhaustive
Freely
Safe to repeat unchanged, with no mutation ID to deduplicate by.
A non-mutating light command, which is the common case — and also a
mutating one the cluster answers the same way however many times it
arrives, where the mutation cache would not have covered it anyway.
Client::suspend_operation and
Client::update_operation_parameters
are the two: suspending a suspended operation is accepted, and setting
a pool assigns rather than increments.
Idempotent is not the same as consequence-free. A retry sent after
the scheduler has let the operation go is answered No such operation,
so a change that was applied can still be reported as an error. Each of
those two commands says so; a mutating command classified here needs the
same reasoning written down beside it.
WithMutationId
Mutating and light: repeat it tagged with a mutation_id.
The cluster keeps the first response for five to ten minutes and hands
it back rather than applying the change twice. See MutationId.
Never
Mutating outside the master’s mutation cache. Sent once, whatever the policy says, because there is nothing that would deduplicate a second send and the first may already have been applied.
Heavy
Heavy: table and file data, in either direction.
Sent once, like Repeatable::Never and for the documented reason —
the way to make a heavy command atomic is a transaction, not a retry.
It also decides where the command goes. A large installation gives
its proxies roles and refuses a heavy request on a control proxy, so
the client asks /hosts for a pool of proxies that will take one —
only when a heavy command needs it, and again when the answer outlives
its refresh interval. Nothing about the call site
changes: this is the same isHeavy bit of the cluster’s command
registry that says the command cannot be repeated, and both answers
follow from writing it down once. The discovered host is constrained to
the configured address’s own domain — see
Client::with_heavy_proxies_anywhere.
write_table, read_table, write_file, read_file, get_job_input
and get_job_stderr are the modelled ones — every one of them declared
isHeavy = true in REGISTER_ALL/REGISTER in the cluster’s
driver registry,
whose argument order is (command, name, inDataType, outDataType, isVolatile, isHeavy). A raw command that streams in either direction is
sent this way whatever the caller says, because streaming is the heavy
shape.
Trait Implementations§
Source§impl Clone for Repeatable
impl Clone for Repeatable
Source§fn clone(&self) -> Repeatable
fn clone(&self) -> Repeatable
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more