When an Event is not published from an Aggregate, so in Axon Framework 4 terms an EventMessage instead of a DomainEventMessage is published, we copy the messageIdentifier into the aggregateIdentifier field and default the sequenceNumber to 0 when storing the event.
We do so to comply with the uniqueness constraint placed on the aggregateIdentifier-to-sequenceNumber combination by the EventStorageEngine.
Although both are actually null in these cases, indices typically expect these fields to be non-null due to the uniqueness constraint.
Regardless, it is worth testing whether we can make non-domain events simply not store the aggregate identifier and sequence number.
Furthermore, given our investigation into the dynamic consistency boundary (DCB for short), which will likely eliminate the need for the separate sequenceNumber field altogether, there's a chance the constraint would no longer apply anyway, and thus, the field's defaulting to 0 would be removed altogether.
This issue still carries the label "under discussion" as it is hard to provide a 100% certainty on the feasibility of this issue right now.
However, if we are to pick up this issue, we should do it before we release Axon Framework 5, due to the breaking changes this would introduce.
When an Event is not published from an Aggregate, so in Axon Framework 4 terms an
EventMessageinstead of aDomainEventMessageis published, we copy themessageIdentifierinto theaggregateIdentifierfield and default thesequenceNumberto 0 when storing the event. We do so to comply with the uniqueness constraint placed on theaggregateIdentifier-to-sequenceNumbercombination by theEventStorageEngine. Although both are actuallynullin these cases, indices typically expect these fields to be non-null due to the uniqueness constraint.Regardless, it is worth testing whether we can make non-domain events simply not store the aggregate identifier and sequence number.
Furthermore, given our investigation into the dynamic consistency boundary (DCB for short), which will likely eliminate the need for the separate
sequenceNumberfield altogether, there's a chance the constraint would no longer apply anyway, and thus, the field's defaulting to0would be removed altogether.This issue still carries the label "under discussion" as it is hard to provide a 100% certainty on the feasibility of this issue right now. However, if we are to pick up this issue, we should do it before we release Axon Framework 5, due to the breaking changes this would introduce.