Current state: Adopted
Discussion thread: here
Vote thread: here
PULL REQUEST: #6284
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
The existing MaskField SMT uses null value equivalent for all types of fields masked.
We want to introduce custom replacement value for any string or numeric fields, which may be optionally specified in config.
- mask out any Personally Identifiable Information (PII) with custom replacement
- SSN → ***-***-****
- IP → XXX.XXX.XXX.XXX
- Telephone number → +0-000-000-0000
'replacement' param value, if specified in config, will be applied to all fields in the 'fields' param list. This way user can mask any string or numeric value with any literal of his choice.
New param 'replacement' will be added to the MaskField SMT config. Param is optional so this change is backward compatible.
custom value replacement, that will be applied to all 'fields' values
(numeric or non-empty string values convertable to the 'fields' type(s)).
non-empty string with numeric or text value, which can be converted to 'fields' type(s)
With config described above there will be 3 transformations, first and second will replace value in a single field, while third will be applied to both 'office' and 'phone' fields.
If replacement provided cannot be converted to the target field type or field type is not supported then org.apache.kafka.connect.errors.DataException will be thrown.
Only numeric (byte, short, int, long, float, double, BigInteger, BigDecimal) and String fields can be replaced with custom value.
Replacing Date, Map or List with custom value seems to be useless and makes conversion logic more complicated.
Add 'replacement' param to config definition:
Define mapping functions for custom replacement value:
Define replacement function:
Compatibility, Deprecation, and Migration Plan
The new configuration property in this proposal is backward compatible, so any existing connector configurations that use the MaskField SMT will continue to work as-is with no behavioral changes. To use the replacement feature, such existing connector configurations will need to be modified to add a new `replacement` property.
First version of the improvement, proposed in the PR, used JSON map of maskField → replacement, this approach had both pros and cons:
JSON-like definition for custom replacement makes MaskField SMT more functional, as user can provide replacements for different fields using single transformation like it was done for default replacements;
JSON-like definition is complicated for the user;
JSON-like definition is more error-prone;
JSON-like definition is less readable;
JSON-like definition processing makes code more complex;
JSON-like definition does not comply with existing configurations for anything in Connect.
Based on the reasons stated above, we choose using single replacement for all mask fields provided, as it is always possible to use multiple MaskField SMT instances in a connector.