@@ -155,21 +155,22 @@ pub trait ProcessorTrait: Send + Sync + Debug {
155
155
}
156
156
157
157
/// This enum captures the configs for all the different processors that are defined.
158
+ ///
158
159
/// The configs for each processor should only contain configuration specific to that
159
160
/// processor. For configuration that is common to all processors, put it in
160
161
/// IndexerGrpcProcessorConfig.
161
162
#[ derive( Clone , Debug , Deserialize , Serialize , strum:: IntoStaticStr , strum:: EnumDiscriminants ) ]
162
163
#[ serde( tag = "type" , rename_all = "snake_case" ) ]
163
- // What is all this strum stuff? Let me explain.
164
- //
165
- // Previously we had consts called NAME in each module and a function called `name` on
166
- // the ProcessorTrait. As such it was possible for this name to not match the snake case
167
- // representation of the struct name. By using strum we can have a single source for
168
- // processor names derived from the enum variants themselves.
169
- //
170
- // That's what this strum_discriminants stuff is, it uses macro magic to generate the
171
- // ProcessorName enum based on ProcessorConfig. The rest of the derives configure this
172
- // generation logic, e.g. to make sure we use snake_case.
164
+ /// What is all this strum stuff? Let me explain.
165
+ ///
166
+ /// Previously we had consts called NAME in each module and a function called `name` on
167
+ /// the ProcessorTrait. As such it was possible for this name to not match the snake case
168
+ /// representation of the struct name. By using strum we can have a single source for
169
+ /// processor names derived from the enum variants themselves.
170
+ ///
171
+ /// That's what this strum_discriminants stuff is, it uses macro magic to generate the
172
+ /// ProcessorName enum based on ProcessorConfig. The rest of the derives configure this
173
+ /// generation logic, e.g. to make sure we use snake_case.
173
174
#[ strum( serialize_all = "snake_case" ) ]
174
175
#[ strum_discriminants(
175
176
derive(
@@ -226,14 +227,16 @@ impl ProcessorConfig {
226
227
}
227
228
}
228
229
229
- /// This enum contains all the processors defined in this crate. We use enum_dispatch
230
- /// as it is more efficient than using dynamic dispatch (Box<dyn ProcessorTrait>) and
230
+ /// This enum contains all the processors defined in this crate.
231
+ ///
232
+ /// We use enum_dispatch as it is more efficient than using dynamic dispatch (Box<dyn ProcessorTrait>) and
231
233
/// it enables nice safety checks like in we do in `test_processor_names_complete`.
232
- #[ enum_dispatch( ProcessorTrait ) ]
233
- #[ derive( Debug ) ]
234
- // To ensure that the variants of ProcessorConfig and Processor line up, in the testing
234
+ ///
235
+ /// // To ensure that the variants of ProcessorConfig and Processor line up, in the testing
235
236
// build path we derive EnumDiscriminants on this enum as well and make sure the two
236
237
// sets of variants match up in `test_processor_names_complete`.
238
+ #[ enum_dispatch( ProcessorTrait ) ]
239
+ #[ derive( Debug ) ]
237
240
#[ cfg_attr(
238
241
test,
239
242
derive( strum:: EnumDiscriminants ) ,
@@ -271,8 +274,10 @@ mod test {
271
274
use strum:: VariantNames ;
272
275
273
276
/// This test exists to make sure that when a new processor is added, it is added
274
- /// to both Processor and ProcessorConfig. To make sure this passes, make sure the
275
- /// variants are in the same order (lexicographical) and the names match.
277
+ /// to both Processor and ProcessorConfig.
278
+ ///
279
+ /// To make sure this passes, make sure the variants are in the same order
280
+ /// (lexicographical) and the names match.
276
281
#[ test]
277
282
fn test_processor_names_complete ( ) {
278
283
assert_eq ! ( ProcessorName :: VARIANTS , ProcessorDiscriminants :: VARIANTS ) ;
0 commit comments