Apply(command) method for a new column in table

Axon Framework
1

Hi,

I am learning all about the Axon Framework and I am incorporating it into my Spring boot application for event sourcing.

I have gotten to the point where I am able to record the sequence of events throughout the different microservices in my application but I have gotten to a requirement where I want a person to be able to go through the process again but with a different version of their original request, but using the same “propId”.

What happens at the moment is, I am receiving from my front end, the “propId” and the “propVersion” fields. On the first propVersion, everything works smoothly. However, when I get to the second propVersion, of course this throws an error as there is a duplicate primary key (propId, sequenceNum).

Looking at the apply method, the only two fields it seems like I can save to the db are payload and the meta data.

I am slightly inexperienced and have tried to search for something without success, but is there a way for me to create a new column in the axon generated DomainEvent table and populate this from my CommandHandler or is that not something which is within the framework?

My idea of a workaround is to write a method to do this population of this new column myself, by updating the column with the “propVersion” after each CommandHandler call, but that’s just an alternative, or if anyone has any better ideas that would be great!

2

The EventStore within Axon, whether this is JPA, Mongo, or Axon Server, has a uniqueness constraint no the aggregate-identifier / sequence-number combination. This is in place to ensure your aggregate isn’t loaded/created concurrently on different machines. Thus it is a safeguard within a distributed environment.

As such, you are required to provide a different aggregateId. Or, to customize the EventStorageEngine and the DomainEventEntry to include the new column and use it during the uniqueness check. Although the second scenario is something I’ve done in the past, I wouldn’t recommend it per se. Going for a different aggregate is far simpler.

As you want to reuse the propId however, we need to do something smart. Axon will invoke the toString() method on the @AggregateIdentifier field inside your aggregate. Thus, if we adjust what the toString() method returns, we can work around this predicament. So instead of directly returning the outcome of the propid, you could go for a dedicated type class (e.g. a TypedId). This TypedId can contain both the propId and the propVersion field. Lastly, the TypedId#toString() method will return a combination of both, instead of just your porpId.

Doing this will tell Axon Framework you have a different aggregate identifier, whilst form your application you are still using the same identifier.