-
Enhancement
-
Resolution: Unresolved
-
Major
-
None
-
None
-
False
-
None
-
False
-
-
Enhance ExtractNewRecordState "delete.handling.mode" config values names and enhance the documentation in ExtractNewRecordStateConfigDefinition and the config option quick reference (table with all config options) in the docs.
I suggest changing the config option values for `delete.handling.mode` in the ExtractNewRecordState SMT to "drop", "tombstone" and "keep".
Furthermore I think it is possible to emit 2 tombstone events for one DELETE operation when `delete.handling.mode=tombstone` and `drop.tombstones=false`. Maybe it makes sense to combine both options into `delete.handling.mode` (and thus remove `drop.tombstones`)?
I suggest `tombstone` to be the default for the new `delete.handling.mode`.
This is how the API might look like for RHOC processors/SMTs:
{ "delete_handling_mode" : { "title": "Handle DELETE events", "description": "When set to \"tombstone\" for each DELETE operation a tombstone record will be send to Kafka. When set to \"drop\" DELETE event records will be removed from the stream and not send to Kafka. When set to \"keep\" DELETE event records will be emitted to the stream and send to Kafka.", "type" : "string", "default" : "tombstone", "enum" : ["tombstone", "drop", "keep"] } }
Furthermore, if we keep the current behavior the quick reference (table with all config options) in the Debezium ExtractNewRecordState SMT docs could be optimized to reflect the info that's only given in the detailed docs section (referring to what events get emitted, when we don't want to combine `delete.handling.mode` and `drop.tombstones`). This also applies to the description texts in the fields in the ExtractNewRecordStateConfigDefinition class.