sthetland commented on a change in pull request #9804:
URL: https://github.com/apache/druid/pull/9804#discussion_r420454207
##########
File path: docs/development/extensions-core/kafka-ingestion.md
##########
@@ -122,9 +122,9 @@ A sample supervisor spec is shown below:
|Field|Description|Required|
|--------|-----------|---------|
|`type`|The supervisor type, this should always be `kafka`.|yes|
-|`dataSchema`|The schema that will be used by the Kafka indexing task during
ingestion, see [`dataSchema`](../../ingestion/index.md#dataschema) for
details.|yes|
-|`ioConfig`|A KafkaSupervisorIOConfig to configure the supervisor and indexing
tasks, see below.|yes|
-|`tuningConfig`|A KafkaSupervisorTuningConfig to configure the supervisor and
indexing tasks, see below.|no|
+|`dataSchema`|The schema that will be used by the Kafka indexing task during
ingestion. See [`dataSchema`](../../ingestion/index.md#dataschema) for
details.|yes|
+|`tuningConfig`|A KafkaSupervisorTuningConfig object for configuring
performance-related settings for the supervisor and indexing tasks. See
[KafkaSupervisorTuningConfig](#kafkasupervisortuningconfig) below.|no|
+|`ioConfig`|A KafkaSupervisorIOConfig object for configuring Kafka connection
and I/O-related settings for the supervisor and indexing task. See
[KafkaSupervisorIOConfig](#kafkasupervisorioconfig) below.|yes|
Review comment:
So you mean put `ioConfig` before `tuningConfig` in the [sample
supervisor
spec](https://druid.apache.org/docs/latest/development/extensions-core/kafka-ingestion.html#submitting-a-supervisor-spec),
[table](https://druid.apache.org/docs/latest/development/extensions-core/kafka-ingestion.html#supervisor-configuration),
and the individual sections, i.e.,
[KafkaSupervisorTuningConfig](https://druid.apache.org/docs/latest/development/extensions-core/kafka-ingestion.html#kafkasupervisortuningconfig)?
That could be better, yes. Especially if, as an optional property, it's not
likely to be touched a lot. But I don't think it's huge deal. I do recommend
consistency in the order, at least.
And that probably wouldn't be able to be a blanket rule, presumably? that
is, I could imagine cases where an optional property came before a mandatory
one to be near closely related properties for instance.
But yeah, if such a circumstance don't apply here, I could reverse them in
the spec example and the sections, and revert the order change in this table?
Let me know if you think so.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
