Kai Moritz [Tue, 11 Jun 2024 18:41:30 +0000 (20:41 +0200)]
query: 2.0.0 - Values are serialized as JSON
--
works, still startling, but explainable
* Splitting the command ``table()``, that reads the input-topic and
materializes it as ``KTable()``, into the two statements ``stream()``,
that reads the input-topic into a ``KStream``, and ``toTable()``, that
turns the `KStream` into a ``KTable``, the ``JsonSerde``, that is
specified via ``Consumed.with(..)``, is only used for the serialization
and deserialization concerning the ``KTable`` -- not the deserialization
of the values, that are read from the input-topic.
* Hence, the type-mappings does not have to be specified for the
``JsonSerde``, resulting in better understandable code.
* __Note__, that the resulting topology does not differe, because the
DSL is able to combine the effects of the two statements.
Kai Moritz [Tue, 11 Jun 2024 18:36:58 +0000 (20:36 +0200)]
query: 2.0.0 - Values are serialized as JSON
--
works, but is very confusing
* The default-type is specified as a consumption-parameter in the command,
that reads the input topic into the `KTable` via ``Consumed.with(..)``.
* The resulting code is confusing, because the ``Consumed``-parameter is
used for both, the consumption of the input topic _and_ the consumption
of stored values, if read from the state-store.
* Because of this, one might only think of the consumption of the stored
values from the state-store, when looking at the ``Consumed.with()``-
statement, and argue, why the type-mappings have to be specified here.
Kai Moritz [Sun, 9 Jun 2024 18:44:35 +0000 (20:44 +0200)]
query: 2.0.0 - (GREEN) Values are serialized as JSON
--
works __only__, if a default-type is defined
* The default-type is needed, to deserialized values that are read from the
state-store.
* Without it, the deserialization fails, because not type-information is
available.
* The type-information gets lost, when the values are stored in the state-
store, because the message-headers are _not_ stored along with the value!