Kai Moritz [Wed, 12 Jun 2024 21:08:57 +0000 (23:08 +0200)]
query: 2.0.0 - (RED) Corrected expectations for the ``users``-input-topic
* The messages that are written by the `users` service doese _not_ contain
any type-information.
* This commits corrects the corresponding expectations in the test-cases.
* *RED:* The tests fail, because the implementation was not yet fixed!
Kai Moritz [Wed, 12 Jun 2024 21:08:57 +0000 (23:08 +0200)]
query: 2.0.0 - `QueryApplicationIT` uses two ``KafkaTemplate``s
* Switched the setup of the `QueryApplicationIT` to use two different
instances of `KafkaTemplate` for the two input-topics.
* This is a preparation for the introduction of the typed JSON-keys.
Kai Moritz [Wed, 12 Jun 2024 20:46:24 +0000 (22:46 +0200)]
query: 2.0.0 - Configured caching & commit-interval in integration-test
* Introduced configuration-parameters for caching and the commit-interval.
* Explicitly turned of caching in the integration-test.
* Explicitly set the commit-interval to a very short period (100ms) in the
integration-test.
Kai Moritz [Wed, 12 Jun 2024 20:46:24 +0000 (22:46 +0200)]
query: 2.0.0 - Defined 2 state-stores (all state in-memory in tests)
* Introduced a second state-store to store the incomming users-table.
* Without the explicit definition of the state-store, it is _not_ possible,
to reconfigure the integration-test in such a way, taht it does not
store its state locally on disk.
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!