pub struct Topology { /* private fields */ }Expand description
A Processor-API topology under construction.
Node insertion order is significant. It sets the subtopology indices, which match the JVM.
Implementations§
Source§impl Topology
impl Topology
pub fn new() -> Self
Sourcepub fn add_source<K, V>(
&mut self,
name: impl Into<String>,
topics: impl IntoIterator<Item = impl Into<String>>,
) -> NodeHandle<K, V>
pub fn add_source<K, V>( &mut self, name: impl Into<String>, topics: impl IntoIterator<Item = impl Into<String>>, ) -> NodeHandle<K, V>
Add a source node reading the given external topics with the default
serdes for K and V, returning a typed NodeHandle used to wire
children to it.
Use Topology::add_source_explicit when either type has no default
serde or when a topology needs custom serdes.
Sourcepub fn add_source_explicit<K, V, KS, VS>(
&mut self,
name: impl Into<String>,
topics: impl IntoIterator<Item = impl Into<String>>,
consumed: impl Into<Consumed<KS, VS>>,
) -> NodeHandle<K, V>
pub fn add_source_explicit<K, V, KS, VS>( &mut self, name: impl Into<String>, topics: impl IntoIterator<Item = impl Into<String>>, consumed: impl Into<Consumed<KS, VS>>, ) -> NodeHandle<K, V>
Add a source node reading the given external topics with explicit serdes,
returning a typed NodeHandle used to wire children to it.
consumed carries the key serde and the value serde. At runtime they
deserialize incoming bytes into typed Record<K, V> values. Write it as
Consumed::with(key_serde, value_serde) so the two roles are visible.
Prefer Topology::add_source, the default-serde form, for types that
implement DefaultSerde. Use this escape hatch when a type has no
default serde, or to override the default for a topic. Examples are a
hand-rolled Serde<T>, a key-role schema serde
(AvroSerde::<T>::key(&cache)), and a validation-on JSON serde
(JsonSerde::value(&cache, true)).
Sourcepub fn add_processor<KIn, VIn, KOut, VOut, S, P, I>(
&mut self,
name: impl Into<String>,
supplier: S,
parents: I,
) -> NodeHandle<KOut, VOut>where
KIn: Any + Send,
VIn: Any + Send,
KOut: Any + Send + Clone,
VOut: Any + Send + Clone,
S: ProcessorSupplier<KIn, VIn, KOut, VOut> + Clone,
I: IntoIterator<Item = P>,
P: Borrow<NodeHandle<KIn, VIn>>,
pub fn add_processor<KIn, VIn, KOut, VOut, S, P, I>(
&mut self,
name: impl Into<String>,
supplier: S,
parents: I,
) -> NodeHandle<KOut, VOut>where
KIn: Any + Send,
VIn: Any + Send,
KOut: Any + Send + Clone,
VOut: Any + Send + Clone,
S: ProcessorSupplier<KIn, VIn, KOut, VOut> + Clone,
I: IntoIterator<Item = P>,
P: Borrow<NodeHandle<KIn, VIn>>,
Add a processor node fed by the given parent NodeHandles, returning a
handle for its output.
Wiring is by value. Every parent’s output type must equal this
processor’s input type (KIn, VIn), and the compiler enforces this.
supplier produces a fresh Processor per task. The closure form
|| MyProc satisfies ProcessorSupplier through a blanket impl, and
it infers all four KV type parameters from the processor’s Processor
impl, so callers never annotate them.
Sourcepub fn add_sink<K, V>(
&mut self,
name: impl Into<String>,
topic: impl Into<String>,
parents: impl IntoIterator<Item = impl Borrow<NodeHandle<K, V>>>,
)
pub fn add_sink<K, V>( &mut self, name: impl Into<String>, topic: impl Into<String>, parents: impl IntoIterator<Item = impl Borrow<NodeHandle<K, V>>>, )
Add a sink node writing to topic with the default serdes for K and
V, fed by the given parent NodeHandles. Every parent’s output type
must equal the sink’s input type (K, V), and the compiler enforces this.
Use Topology::add_sink_explicit when either type has no default serde
or when a topology needs custom serdes.
Sourcepub fn add_sink_explicit<K, V, KS, VS, P, I>(
&mut self,
name: impl Into<String>,
topic: impl Into<String>,
parents: I,
produced: impl Into<Produced<KS, VS>>,
)
pub fn add_sink_explicit<K, V, KS, VS, P, I>( &mut self, name: impl Into<String>, topic: impl Into<String>, parents: I, produced: impl Into<Produced<KS, VS>>, )
Add a sink node writing to topic with explicit serdes, fed by the given
parent NodeHandles. Every parent’s output type must equal the sink’s
input type (K, V), and the compiler enforces this.
produced carries the key serde and the value serde that serialize
outgoing records. Write it as Produced::with(key_serde, value_serde).
A sink is terminal, so this method returns nothing.
Prefer Topology::add_sink, the default-serde form, for types that
implement DefaultSerde. Use this escape hatch when a type has no
default serde, or to override the default for a topic. Examples are a
hand-rolled Serde<T>, a key-role schema serde
(AvroSerde::<T>::key(&cache)), and a validation-on JSON serde
(JsonSerde::value(&cache, true)).
Sourcepub fn add_state_store<K, V, KS, VS>(
&mut self,
name: impl Into<String>,
key_serde: KS,
value_serde: VS,
processors: impl IntoIterator<Item = impl Into<String>>,
) -> &mut Self
pub fn add_state_store<K, V, KS, VS>( &mut self, name: impl Into<String>, key_serde: KS, value_serde: VS, processors: impl IntoIterator<Item = impl Into<String>>, ) -> &mut Self
Register a state store connected to the given processors, with a changelog.
key_serde and value_serde define how the store serializes records
into the changelog topic (<app_id>-<name>-changelog) and into the
store’s byte map. Stores connect processors that can have different
types, so the processor list uses names. Pass NodeHandle::name for a
handle you hold.
Sourcepub fn add_state_store_with_changelog<K, V, KS, VS>(
&mut self,
name: impl Into<String>,
key_serde: KS,
value_serde: VS,
processors: impl IntoIterator<Item = impl Into<String>>,
changelog_topic: impl Into<String>,
) -> &mut Self
pub fn add_state_store_with_changelog<K, V, KS, VS>( &mut self, name: impl Into<String>, key_serde: KS, value_serde: VS, processors: impl IntoIterator<Item = impl Into<String>>, changelog_topic: impl Into<String>, ) -> &mut Self
Register a state store whose changelog is an existing source topic
rather than the derived <app_id>-<name>-changelog.
This backs the REUSE_KTABLE_SOURCE_TOPICS DSL optimizer. A
builder.table_explicit(topic, ...) store can reuse topic as its
changelog. No separate app-<store>-changelog topic is created, and the
wire topology lists topic as the store’s changelog. changelog_topic
is the topic name used both in the wire state_changelog_topics entry
and as the runtime store’s changelog target.
Sourcepub fn add_window_store<K, V, KS, VS>(
&mut self,
name: impl Into<String>,
key_serde: KS,
value_serde: VS,
window: (Time, Time, Time),
processors: impl IntoIterator<Item = impl Into<String>>,
) -> &mut Self
pub fn add_window_store<K, V, KS, VS>( &mut self, name: impl Into<String>, key_serde: KS, value_serde: VS, window: (Time, Time, Time), processors: impl IntoIterator<Item = impl Into<String>>, ) -> &mut Self
Register a windowed state store connected to the given processors.
Like add_state_store but for windowed stores. The changelog topic
carries compact,delete configs and a retention.ms derived from
size + grace + [CHANGELOG_ADDITIONAL_RETENTION].
The tuple is (retention_basis, window_size, grace). The retention
basis sets the changelog retention.ms. For tumbling and hopping
windows it equals the window size. For sliding windows it is the
retention span (2 * time_difference), which is wider than the window.
The window size is the true window length. Only the store’s cache
flush uses it, to rebuild the downstream Windowed<K> key’s
end = start + window_size, because the store-key bytes hold only the
start. For sliding windows this is time_difference (1x), NOT the
retention span.
Sourcepub fn add_join_window_store<K, V, KS, VS>(
&mut self,
name: impl Into<String>,
key_serde: KS,
value_serde: VS,
window: (Time, Time, Time),
processors: impl IntoIterator<Item = impl Into<String>>,
) -> &mut Self
pub fn add_join_window_store<K, V, KS, VS>( &mut self, name: impl Into<String>, key_serde: KS, value_serde: VS, window: (Time, Time, Time), processors: impl IntoIterator<Item = impl Into<String>>, ) -> &mut Self
Register a join window state store connected to the given processors.
Like add_window_store but for join window stores (retainDuplicates).
The changelog topic carries delete-only configs and a retention.ms
derived from before + after + grace + [CHANGELOG_ADDITIONAL_RETENTION].
Compaction is not applicable because the store retains duplicates.
Sourcepub fn add_session_store<K, V, KS, VS>(
&mut self,
name: impl Into<String>,
key_serde: KS,
value_serde: VS,
gap: Time,
grace: Time,
processors: impl IntoIterator<Item = impl Into<String>>,
) -> &mut Self
pub fn add_session_store<K, V, KS, VS>( &mut self, name: impl Into<String>, key_serde: KS, value_serde: VS, gap: Time, grace: Time, processors: impl IntoIterator<Item = impl Into<String>>, ) -> &mut Self
Register a session state store connected to the given processors.
Like add_window_store but for session stores. It reuses the windowed
(compact,delete) changelog config. The retention.ms comes from
gap + grace + [CHANGELOG_ADDITIONAL_RETENTION]. The store holds the
raw aggregate (SessionBytesStore).
Sourcepub fn add_versioned_store<K, V, KS, VS>(
&mut self,
name: impl Into<String>,
key_serde: KS,
value_serde: VS,
history_retention: Time,
processors: impl IntoIterator<Item = impl Into<String>>,
) -> &mut Self
pub fn add_versioned_store<K, V, KS, VS>( &mut self, name: impl Into<String>, key_serde: KS, value_serde: VS, history_retention: Time, processors: impl IntoIterator<Item = impl Into<String>>, ) -> &mut Self
Register a versioned state store (KIP-889) connected to the given processors.
The changelog topic carries compact + min.compaction.lag.ms = history_retention + [CHANGELOG_ADDITIONAL_RETENTION]. The
version-chain store is self-contained in memory, so it does not use the
supplied byte backend.
Sourcepub fn add_versioned_store_with_changelog<K, V, KS, VS>(
&mut self,
name: impl Into<String>,
key_serde: KS,
value_serde: VS,
history_retention: Time,
processors: impl IntoIterator<Item = impl Into<String>>,
changelog_topic: impl Into<String>,
) -> &mut Self
pub fn add_versioned_store_with_changelog<K, V, KS, VS>( &mut self, name: impl Into<String>, key_serde: KS, value_serde: VS, history_retention: Time, processors: impl IntoIterator<Item = impl Into<String>>, changelog_topic: impl Into<String>, ) -> &mut Self
Like add_versioned_store but the changelog is an existing source
topic. The REUSE_KTABLE_SOURCE_TOPICS optimizer points a versioned
builder.table_explicit(topic, …) store’s changelog at its own source
topic. This mirrors add_state_store_with_changelog.
Sourcepub fn add_suppress_store<K, V, KS, VS>(
&mut self,
name: impl Into<String>,
key_serde: KS,
value_serde: VS,
logging: bool,
processors: impl IntoIterator<Item = impl Into<String>>,
) -> &mut Self
pub fn add_suppress_store<K, V, KS, VS>( &mut self, name: impl Into<String>, key_serde: KS, value_serde: VS, logging: bool, processors: impl IntoIterator<Item = impl Into<String>>, ) -> &mut Self
Register a suppress buffer store connected to the given processor.
The suppress buffer (SuppressBytesStore) is a time-ordered in-memory
buffer with its own storage. It does NOT use the pluggable byte backend,
so the factory ignores the opened backend.
logging toggles ONLY the changelog. When true, the wire topology
gets the changelog topic, a plain cleanup.policy=compact changelog,
because the JVM suppress buffer is a compacted KV store, and the store
logs and restores. When false, the store stays in memory and NO
changelog topic appears, so a logging-off suppress has the same wire
shape as an unsuppressed topology.
Sourcepub fn add_global_store<K, V, KS, VS>(
&mut self,
store_name: impl Into<String>,
source_name: impl Into<String>,
topic: impl Into<String>,
processor_name: impl Into<String>,
consumed: impl Into<Consumed<KS, VS>>,
) -> &mut Self
pub fn add_global_store<K, V, KS, VS>( &mut self, store_name: impl Into<String>, source_name: impl Into<String>, topic: impl Into<String>, processor_name: impl Into<String>, consumed: impl Into<Consumed<KS, VS>>, ) -> &mut Self
Register a GlobalKTable source, update-processor, and KV store.
A GlobalKTable is invisible in the wire. It has no subtopology of
its own and no changelog topic. Its source node still takes a node-group
index during grouping, so other subtopology ids shift. This method does
three things:
- it registers a source node reading
topicand a processor node fed by it, and the source→processor edge unites them into one node group; - it marks
topicglobal so the grouping pass skips it in the source-bucketing pass. The final filter drops the resulting source-less group, but that group already took its index; - it stores the global KV factory in a SEPARATE map
(
global_store_factories, NOTstore_factories) so per-taskinstantiatedoes not build it and NO changelog topic is emitted. The factory builds aKeyValueBytesStorewith an empty changelog.
Per-task instantiate does not build the global store. The
fully-replicated global-store manager reads the factory.
Sourcepub fn connect_processor_store(
&mut self,
processor: &str,
store: &str,
) -> &mut Self
pub fn connect_processor_store( &mut self, processor: &str, store: &str, ) -> &mut Self
Connect an additional processor to an already-registered state store.
This mirrors InternalTopologyBuilder.connectProcessorAndStateStores. A
join processor must read the joined table’s store even though it was not
the store’s original owner. The grouping pass unions all connected
processors into one subtopology, so a second processor here is enough to
pull the join processor into the same subtopology as the store.
Sourcepub fn add_repartition_topic<S: Into<String>>(&mut self, name: S) -> &mut Self
pub fn add_repartition_topic<S: Into<String>>(&mut self, name: S) -> &mut Self
Register a topic name as an internal repartition topic.
Sourcepub fn add_copartition_group(
&mut self,
topics: impl IntoIterator<Item = impl Into<String>>,
) -> &mut Self
pub fn add_copartition_group( &mut self, topics: impl IntoIterator<Item = impl Into<String>>, ) -> &mut Self
Declare a copartition group. The given member topics must share a partitioning.
The grouping pass assigns the group to the subtopology that reads its
members. The wire layer encodes member names as int16 indices into that
subtopology’s sorted source and repartition arrays. Joins need this
(KIP-1071).
Sourcepub fn build<S: Into<String>>(
self,
application_id: S,
) -> Result<BuiltTopology, TopologyError>
pub fn build<S: Into<String>>( self, application_id: S, ) -> Result<BuiltTopology, TopologyError>
Derive subtopologies and the wire topology.
application_id sets the internal-topic names
(<app>-<store>-changelog).
The typed NodeHandle wiring already guarantees that parent→child KV
types match, so build() checks only the structural invariants: no
duplicate names, every predecessor exists, and at least one source. The
wire Topology is byte-identical to the untyped implementation.
§Errors
Returns an error when configuration is invalid, protocol encoding fails, the broker rejects the request, or transport I/O fails.
Trait Implementations§
Auto Trait Implementations§
impl !RefUnwindSafe for Topology
impl !UnwindSafe for Topology
impl Freeze for Topology
impl Send for Topology
impl Sync for Topology
impl Unpin for Topology
impl UnsafeUnpin for Topology
Blanket Implementations§
§impl<'a, T, E> AsTaggedExplicit<'a, E> for Twhere
T: 'a,
impl<'a, T, E> AsTaggedExplicit<'a, E> for Twhere
T: 'a,
§impl<'a, T, E> AsTaggedImplicit<'a, E> for Twhere
T: 'a,
impl<'a, T, E> AsTaggedImplicit<'a, E> for Twhere
T: 'a,
Source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere
T: ?Sized,
Source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
impl<ST, DT> CastableFrom<ST, Initialized, Initialized> for DT
impl<ST, DT> CastableFrom<ST, Uninit, Uninit> for DT
§impl<K, Q> Comparable<Q> for K
impl<K, Q> Comparable<Q> for K
§impl<T> Downcast for Twhere
T: Any,
impl<T> Downcast for Twhere
T: Any,
§fn into_any(self: Box<T>) -> Box<dyn Any>
fn into_any(self: Box<T>) -> Box<dyn Any>
Box<dyn Trait> (where Trait: Downcast) to Box<dyn Any>, which can then be
downcast into Box<dyn ConcreteType> where ConcreteType implements Trait.§fn into_any_rc(self: Rc<T>) -> Rc<dyn Any>
fn into_any_rc(self: Rc<T>) -> Rc<dyn Any>
Rc<Trait> (where Trait: Downcast) to Rc<Any>, which can then be further
downcast into Rc<ConcreteType> where ConcreteType implements Trait.§fn as_any(&self) -> &(dyn Any + 'static)
fn as_any(&self) -> &(dyn Any + 'static)
&Trait (where Trait: Downcast) to &Any. This is needed since Rust cannot
generate &Any’s vtable from &Trait’s.§fn as_any_mut(&mut self) -> &mut (dyn Any + 'static)
fn as_any_mut(&mut self) -> &mut (dyn Any + 'static)
&mut Trait (where Trait: Downcast) to &Any. This is needed since Rust cannot
generate &mut Any’s vtable from &mut Trait’s.§impl<T> DowncastSend for T
impl<T> DowncastSend for T
§impl<T> DowncastSync for T
impl<T> DowncastSync for T
§impl<K, Q> Equivalent<Q> for K
impl<K, Q> Equivalent<Q> for K
§fn equivalent(&self, key: &Q) -> bool
fn equivalent(&self, key: &Q) -> bool
key and return true if they are equal.impl<T> ErasedDestructor for Twhere
T: 'static,
impl<T> Fruit for Twhere
T: Send + Downcast,
§impl<T> Instrument for T
impl<T> Instrument for T
§fn instrument(self, span: Span) -> Instrumented<Self>
fn instrument(self, span: Span) -> Instrumented<Self>
§fn in_current_span(self) -> Instrumented<Self>
fn in_current_span(self) -> Instrumented<Self>
Source§impl<T> IntoEither for T
impl<T> IntoEither for T
Source§fn into_either(self, into_left: bool) -> Either<Self, Self>
fn into_either(self, into_left: bool) -> Either<Self, Self>
self into a Left variant of Either<Self, Self>
if into_left is true.
Converts self into a Right variant of Either<Self, Self>
otherwise. Read moreSource§fn into_either_with<F>(self, into_left: F) -> Either<Self, Self>
fn into_either_with<F>(self, into_left: F) -> Either<Self, Self>
self into a Left variant of Either<Self, Self>
if into_left(&self) returns true.
Converts self into a Right variant of Either<Self, Self>
otherwise. Read more§impl<T> Paint for Twhere
T: ?Sized,
impl<T> Paint for Twhere
T: ?Sized,
§fn fg(&self, value: Color) -> Painted<&T>
fn fg(&self, value: Color) -> Painted<&T>
Returns a styled value derived from self with the foreground set to
value.
This method should be used rarely. Instead, prefer to use color-specific
builder methods like red() and
green(), which have the same functionality but are
pithier.
§Example
Set foreground color to white using fg():
use yansi::{Paint, Color};
painted.fg(Color::White);Set foreground color to white using white().
use yansi::Paint;
painted.white();§fn bright_black(&self) -> Painted<&T>
fn bright_black(&self) -> Painted<&T>
§fn bright_red(&self) -> Painted<&T>
fn bright_red(&self) -> Painted<&T>
§fn bright_green(&self) -> Painted<&T>
fn bright_green(&self) -> Painted<&T>
§fn bright_yellow(&self) -> Painted<&T>
fn bright_yellow(&self) -> Painted<&T>
§fn bright_blue(&self) -> Painted<&T>
fn bright_blue(&self) -> Painted<&T>
§fn bright_magenta(&self) -> Painted<&T>
fn bright_magenta(&self) -> Painted<&T>
§fn bright_cyan(&self) -> Painted<&T>
fn bright_cyan(&self) -> Painted<&T>
§fn bright_white(&self) -> Painted<&T>
fn bright_white(&self) -> Painted<&T>
§fn bg(&self, value: Color) -> Painted<&T>
fn bg(&self, value: Color) -> Painted<&T>
Returns a styled value derived from self with the background set to
value.
This method should be used rarely. Instead, prefer to use color-specific
builder methods like on_red() and
on_green(), which have the same functionality but
are pithier.
§Example
Set background color to red using fg():
use yansi::{Paint, Color};
painted.bg(Color::Red);Set background color to red using on_red().
use yansi::Paint;
painted.on_red();§fn on_primary(&self) -> Painted<&T>
fn on_primary(&self) -> Painted<&T>
§fn on_magenta(&self) -> Painted<&T>
fn on_magenta(&self) -> Painted<&T>
§fn on_bright_black(&self) -> Painted<&T>
fn on_bright_black(&self) -> Painted<&T>
§fn on_bright_red(&self) -> Painted<&T>
fn on_bright_red(&self) -> Painted<&T>
§fn on_bright_green(&self) -> Painted<&T>
fn on_bright_green(&self) -> Painted<&T>
§fn on_bright_yellow(&self) -> Painted<&T>
fn on_bright_yellow(&self) -> Painted<&T>
§fn on_bright_blue(&self) -> Painted<&T>
fn on_bright_blue(&self) -> Painted<&T>
§fn on_bright_magenta(&self) -> Painted<&T>
fn on_bright_magenta(&self) -> Painted<&T>
§fn on_bright_cyan(&self) -> Painted<&T>
fn on_bright_cyan(&self) -> Painted<&T>
§fn on_bright_white(&self) -> Painted<&T>
fn on_bright_white(&self) -> Painted<&T>
§fn attr(&self, value: Attribute) -> Painted<&T>
fn attr(&self, value: Attribute) -> Painted<&T>
Enables the styling [Attribute] value.
This method should be used rarely. Instead, prefer to use
attribute-specific builder methods like bold() and
underline(), which have the same functionality
but are pithier.
§Example
Make text bold using attr():
use yansi::{Paint, Attribute};
painted.attr(Attribute::Bold);Make text bold using using bold().
use yansi::Paint;
painted.bold();§fn rapid_blink(&self) -> Painted<&T>
fn rapid_blink(&self) -> Painted<&T>
§fn quirk(&self, value: Quirk) -> Painted<&T>
fn quirk(&self, value: Quirk) -> Painted<&T>
Enables the yansi [Quirk] value.
This method should be used rarely. Instead, prefer to use quirk-specific
builder methods like mask() and
wrap(), which have the same functionality but are
pithier.
§Example
Enable wrapping using .quirk():
use yansi::{Paint, Quirk};
painted.quirk(Quirk::Wrap);Enable wrapping using wrap().
use yansi::Paint;
painted.wrap();§fn clear(&self) -> Painted<&T>
👎Deprecated since 1.0.1: renamed to resetting() due to conflicts with Vec::clear().
The clear() method will be removed in a future release.
fn clear(&self) -> Painted<&T>
renamed to resetting() due to conflicts with Vec::clear().
The clear() method will be removed in a future release.
§fn whenever(&self, value: Condition) -> Painted<&T>
fn whenever(&self, value: Condition) -> Painted<&T>
Conditionally enable styling based on whether the [Condition] value
applies. Replaces any previous condition.
See the crate level docs for more details.
§Example
Enable styling painted only when both stdout and stderr are TTYs:
use yansi::{Paint, Condition};
painted.red().on_yellow().whenever(Condition::STDOUTERR_ARE_TTY);