I have a situation, where we introduced new event and then released application. Unfortunately we need to rollback this application version so it means that we need to get rid completely of that newly introduced event (we removed that class from our app). Some of the customer used that event and it has been serialized to event store. Now, when applying new events on aggregate, deserialization fails, because java class does not exists anymore.
I would like to know if there is a way to ignore unknown events. There is option in XStream to ignoreElements however this option as i see ignore only fields, not whole classes. I was thinking if upcasting could do that job for me, but not sure how it can be achieved in code. Does anyone had similiar experience ? I need to add that i’m using default XStreamSerializer, nad using old 3.0.x axon framework version
Thanks for answer. Is it possible to safely remove events from event store ? What i’m afraid is to do any data manipulation on production database directly. Especially where many rows will be affected. Or there is another way to do that ?
This event was mistake, because it was bad design. It was completely not necessary to introduce it. It even caused some side effect, so we decided to remove it.
While I really appreciate the contribution brought by @Faik_Siddiqi, if I were you and just a few of records I would prefer to clean my event store up.
The scenario proposed in the link is a depreciation of a business process so it might have dozen of hundreds events that have performed some valid business flow, in you case you mentioned it was a mistake so I tend to think you have just a few of events.
But I think now you have some options to evaluate e apply, discuss with your team and take the decision that works better for you.
Thanks for answers ! Thing is, that we needed to rollback something quickly and effectively. Unfortunately it happens quite often. Then we are hotfixing something (not necessarily related to axon event) but during that time we have this events in db. Really often fixes are also quick, so we don’t want to remove such events.
We finally decided to other solution. I wrote custom stream upcaster and i’m filtering out events for classes which doesn’t exists. It is not best in performance however we made easily to switch on/off. So in case of rollback, we just turn upcaster on (thanks to that events which doesn’t have appriopriate class are ommited) and just after hotfix, we turn it off (then those events again will be available)
Writing a filtering Upcaster would be my recommendation as well. Happy to hear you and your team came to the same conclusion! It offers the most flexibility and is easiest to add classes too. Furthermore, you do not preemptively clear out events you might still need later on. It would be nice if Axon would provide a filtering instance out of the box…something to work on from our end, I think.