Strategy for handling rollback of release if new or changed events are present

[CBloch]

As our axon models evolve, we add new events and make additions to existing events.  We run into issues when something happens after a release and we are forced to backout the changes.  New or changed events may have made their way into the database, so once the changes are backed out, we will get serialization issues for those events when they are re-played.  We are wondering if there is some strategy to manage these cases.  It’s a live system, so we can’t backup and restore the database if the release needs to be backed out.  

[Allard Buijze]

Hi Carol,

some companies I have visited have a "roll-forward only" policy. They never roll back a deployement. Instead, they fix and redeploy.  Unfortunately, that's not (yet) an option for everybody.

In general, my recommendation is to make sure your changes are backward and forward compatible. It's easier said than done, and probably also easier done that you might think. Main thing is to only add new fields, not change/remove any. Your serializer will also have to be lenient. It shouldn't fail if it receives a property it doesn't know. Preferably, it should also not fail when  an expected property is missing.

Axon's serializers aren't lenient by default, but it's easy to configure them to be:

XStream: getXStream().ignoreUnknownElements()

Jackson: objectMapper.disable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES);

Hope this helps.

Cheers,

Allard

Op vr 15 dec. 2017 om 21:57 schreef CBloch <ca...@fit-pay.com>:

As our axon models evolve, we add new events and make additions to existing events.  We run into issues when something happens after a release and we are forced to backout the changes.  New or changed events may have made their way into the database, so once the changes are backed out, we will get serialization issues for those events when they are re-played.  We are wondering if there is some strategy to manage these cases.  It’s a live system, so we can’t backup and restore the database if the release needs to be backed out.  

--
You received this message because you are subscribed to the Google Groups "Axon Framework Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to axonframewor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Allard Buijze

CTO

E: allard...@axoniq.io

T: +31 6 34 73 99 89

AxonIQ Conference - 29th September - in Amsterdam

[CBloch]

Thanks Allard, that will definitely help with a lot of the changes we make.  Is there a way to configure it to ignore entire events it doesn't understand for the cases where we add a new event and need to rollback?

[Allard Buijze]

Hi Carol,

for Event Processors, unknown event types are automatically ignored. However, in the case of Aggregates being event sourced, we have decided to fail by default, instead. The thought behind this, is that when streaming an Aggregate, you should not encounter unknown events, as the aggregate itself is the one who published them. Event Processors, on the other hand, may live in external applications, and they should only need to hold the classes they care about receiving.

It is the EventStorageEngine implementation that explicitly defines certain streams should raise an error when an unknown event type is encountered. You could change this behavior by overriding the org.axonframework.eventsourcing.eventstore.AbstractEventStorageEngine#readEvents(java.lang.String, long) method. Instead of passing "false" as the fourth parameter to EventUtils.upcastAndDeserializeDomainEvents, you simply pass true (i.e. ignore unknown events).

Alternatively, you could wrap/override the behavior on the Serializer, telling it to return a dummy event implementation when an unknown class is encountered.

I am going to give this a bit more thought to see if there is a neater way to resolve this. If you have any ideas, they're most welcome.

Cheers,

Allard

Op ma 18 dec. 2017 om 20:21 schreef CBloch <ca...@fit-pay.com>: