[Axon 2.4.6] Changing the events structure, upcasting or XStream configuration ?

Imported from Google Groups
1

Hi,

I’m using EventSourcing, backed by a JPA repository.

I would like to refactor some of my events, but as my application is already under testing, I’m wondering how I can deal with it gracefully.

Let’s say that I have a event E, with some fields attribute1,attribute2,attribute3.

Now, for some reason, I would like to group attribute1, attribute2, attribute3 inside a value object.

public class E {
private ValueObject valueObject;
}

public class ValueObject {

private String attribute1;
private String attribute2;
private String attribute3;
}

I guess that if I do that without any other modification, I’ll end up with an inconsistent state when my events will be applied to my AggregateRoot (as valueObject will be null, or worse, I’ll get a exception as attribute1, attribute2, attribute3 are not found at this level by the deserializer).

So my question is very simple, to handle that case, what’s the most straightforward (and consistent) way ?

Implementing a upcaster, or using a custom deserializer on XStream side ? (In the case of Xstream, I’m not sure how to deal with the 3 attributes mapping).

The documentation recommends to avoid upcasting when possible, and in the current case, I tend to agree, as I don’t really change the Event itself.

Thank you,

2

this guide from greg young about event sourcing

https://leanpub.com/esversioning/read

3

Hi Jerome,

I’m not sure XStream has an option to “embed” value objects like this, similar to how Hibernate would to it with @Embeddable.

In this case, I would seriously consider the need for anything at all. It seems your application is not in production yet (you mentioned test). Do you really want to add a feature to your application that will never be used in production?
Anyway, if you do, I think you’re better off with an upcaster in this case. The mapping should be fairly simple for this case. You can use Dom4j to modify the XML document (use org.dom4j.Document as expected representation).

Hope this helps.
Cheers,

Allard

4

@Allard :

It surely helps, thank you for the answer. In my case, you are right, it’s not in production yet, but as some data were already created by the key users, I wanted to prevent them to key them in again. I guess that investing some time in some automated provisioning will be worth it, at least as much than writing this upcaster. I’ll keep it as an exercise though, thanks again.

@Meong

Thanks, great resource !

Regards,