Enhancement Description
The Upcaster API serves an important purpose within Axon Framework: it allows events to maintain their original format in the storage solution, while event handlers can take the most recent format applicable for their application through upcasting of the events.
However, given all the changes in Axon Framework, particularly around the Serializer-to-Converter switch (as described in #3102), the old approach doesn't suffice. But, some components are simply no longer required. Through adjusting the Message to contain both the intended type and version (with the MessageType) as maintaining the payloadType to reflect the "data format" of the Message, we got everything that the IntermediateEventRepresentation provided. And more, as it is no longer an event-detail (as with the IntermediateEventRepresentation) but a generic Message detail.
Thus, the Message may serve as the input for upcasters instead of anything else. This shift brings AxonIQ/axoniq-framework#80 one step closer, leaving overall configuration, essentially. To allow for AxonIQ/axoniq-framework#80, we should figure out whether we can make the upcasting a decorator around the "right" components. If so, I deem the chances high that we can remove the upcasting configuration that existed directly on the EventStore and make it a plain ConfigurationEnhancer.
On top of that, we may be able to reuse the Message#withConvertedPayload operation to be the upcasting task itself. This will require adjustments in the Message#withConvertedPayload implementation, as upcasting typically occurs from one Type to the exact same Type, which is currently not possible through withConvertedPayload. Added, we would need a mapping operation, which is not present. Whether we add this to the Message or maintain the actual mapping in the upcaster is up for discussion.
With all that said, we foresee the following tasks as part of this issue:
Current Behaviour
Upcasters reside in the AF4 API, stuck with events, and using the old Serializer.
Wanted Behaviour
Upcasters align with our wishes for AF5, allowed for any Message, and using the Converters instead.
Possible Workarounds
Manual upcasting within the message handling methods.
Enhancement Description
The
UpcasterAPI serves an important purpose within Axon Framework: it allows events to maintain their original format in the storage solution, while event handlers can take the most recent format applicable for their application through upcasting of the events.However, given all the changes in Axon Framework, particularly around the Serializer-to-Converter switch (as described in #3102), the old approach doesn't suffice. But, some components are simply no longer required. Through adjusting the
Messageto contain both the intended type and version (with theMessageType) as maintaining thepayloadTypeto reflect the "data format" of theMessage, we got everything that theIntermediateEventRepresentationprovided. And more, as it is no longer an event-detail (as with theIntermediateEventRepresentation) but a genericMessagedetail.Thus, the
Messagemay serve as the input for upcasters instead of anything else. This shift brings AxonIQ/axoniq-framework#80 one step closer, leaving overall configuration, essentially. To allow for AxonIQ/axoniq-framework#80, we should figure out whether we can make the upcasting a decorator around the "right" components. If so, I deem the chances high that we can remove the upcasting configuration that existed directly on theEventStoreand make it a plainConfigurationEnhancer.On top of that, we may be able to reuse the
Message#withConvertedPayloadoperation to be the upcasting task itself. This will require adjustments in theMessage#withConvertedPayloadimplementation, as upcasting typically occurs from oneTypeto the exact sameType, which is currently not possible throughwithConvertedPayload. Added, we would need a mapping operation, which is not present. Whether we add this to theMessageor maintain the actual mapping in the upcaster is up for discussion.With all that said, we foresee the following tasks as part of this issue:
Current Behaviour
Upcasters reside in the AF4 API, stuck with events, and using the old
Serializer.Wanted Behaviour
Upcasters align with our wishes for AF5, allowed for any
Message, and using theConvertersinstead.Possible Workarounds
Manual upcasting within the message handling methods.