THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
To understand behavior of this configuration with and without schemas, refer to the table below:.
| Source Schema (Info) | JsonConverter Behavior | JsonDeserializer Behavior | |
|---|---|---|---|
| Schemas Enabled | Schemas Disabled | ||
| DECIMAL (BASE64) | returns DECIMAL logical type | throws DataException | stores BinaryNode (byte[] data) |
| DECIMAL (NUMERIC) | returns DECIMAL logical type | returns |
| FLOAT64 (lossy)* | stores NumericNode (BigDecimal data) | |
| FLOAT64 (Legacy) | returns FLOAT64 | returns |
| FLOAT64 | stores NumericNode (Double data) | |
| FLOAT64 (KIP-481) | returns FLOAT64 | returns |
| FLOAT64 | stores NumericNode (BigDecimal data)** |
* previously it was impossible for a sink converter to read decimal data encoded in BASE64 (a DataException was raised when decoding BINARY data without a schema) - after KIP-481, it is possible that a decimal data produced by a source converter with NUMERIC encoding will be deserialized as a float by a sink converter without schemas enabled. The data being read here will be lossy. This is okay because all existing applications will function exactly the same.
** with this behavior, users will be provided with a different NumberNode than previously (DecimalNode vs. DoubleNode). Since Jackson requires calling a strongly typed method (e.g. floatValue vs. decimalValue) to extract data from a NumberNode, applications relying on JsonDeserializer will not be affected by this change
Compatibility, Deprecation, and Migration Plan
- The JsonConverter's serialization behavior is identical to legacy behavior when using the default configuration (decimal.format=BASE64)
- The JsonConverter's deserialization behavior is backwards compatible and can handle data encoded from earlier versionsUpgrading source and sink converters to the new code version in any combination is backwards compatible if decimal.format is left unset or is set to "BASE64" in the source converters.
- To set decimal.format to "NUMERIC" in source converters, all sink converters reading the data (and any other downstream consumers of the source converter output topic) must first upgrade code to include the code change from this KIP.
- Note that the Kafka topic will have messages of mixed serialization format after this change. Rolling back sink converters or any other downstream Kafka consumers to code that cannot handle both formats will be unsafe after upgrading source converters to use NUMERIC serialization formats.
...