@Revision saga support

Imported from Google Groups
1

Hi!

I’ve stumpled upon the revision column in my sagaentry table and was wondering if I could use it for Saga evolution.

I know that the @Revision annotation on events can be used for event upcaster, but up to now I was not aware of the revision column for sagas.

Are there any recommended practices or is there a comparable support in Axon, like event upcasting, that helps me with migrating (unfinished) Sagas?

Should I put @Revision(“1”) on all of my current Sagas for possible future changes?

Cheers,
Andreas

2

Hi Andreas,

For upcasting events we’ve got quite some convenience classes to simplify the live of a upcaster-writing-developer.
For Saga’s, not so much however.
For events we for example have the SingleEventUpcaster, whilst for Saga’s you should provide your own implementation of a SingleEntryUpcaster specific for your Saga you’re upcasting.

Your hunch on using the @Revision annotation to fill the revision column for sagas is correct though.
The Axon Serializers have a RevisionResolver field, which they use to pull the value out of the @Revision annotation, and it does so for Sagas and Events a like.

You are however by no means inclined to put @Revision(“1”) on all your Sagas though.
That’s similarly not required for Events, as it’s perfectly fine for the revision column to start at null and move to 1 (or whatever versioning scheme you’d prefer) after that.

I have been checking in our codebase how to wire the upcasters for a Saga in Axon 3.x, which I’d say should fit in with the Repository or SagaStore, but I’m failing to find where it fits in…
Maybe somebody else can shed some light on that for you (and me in that respect).

So I figure this will shed some light on the situation, although it’s not the full solution yet.
Again, sorry for that.

Cheers,

Steven

3

Hi Andreas, Steven,

upcating was originally intended for use in Event Sourcing. However, the serialization mechanism in Axon is generic. So the revision and type can still be used to do some modifications in the serialized objects (or an intermediate form, such as JSON or XML) before deserializing it. Axon doesn’t provide the Upcasting mechanism out of the box, but you can hook it in if you want. I have seen places where people wrapped the serializer with an UpcastingSerializer, which would invoke an Upcaster first, and then pass the result to a delegate serializer (XStream or Jackson based).

So, if you notice that you need to “migrate” old serialized data to a new form, you could use the revision to do so. Until then, just leave it at null, like Steven suggests. You can start counting once it has become important.

Cheers,

Allard