Migrating SQL persisted Saga data

Leveraging 6th generation NServiceBus on a project with numerous sagas. Currently leveraging both SQL Transport and SQL Persistence.

Over time the refactoring of the system has ended up with 3 distinct types of order processing sagas that have been boiled down to storing the same two columns in the saga data (UserId and OrderId).

Question

  1. There’s no guidance I’ve seen saying that sharing the same saga persistence table isn’t ok. Simultaneously I’ve not seen where it’s exactly said to be kosher either :slight_smile:

  2. If #2 is ok, migrating is as simple as moving the SQL rows into the new combined shared saga state table, correct?

The main differences are:

  • The name and type of the CorrelationId column.
  • The shape of the data in the JSON-serialized field. The SagaId column is a Guid so that will never overlap, but if you got a message that mapped to the CorrelationId, and the JSON data contained there didn’t deserialize to the saga data type, it would blow up.
  • The fact that there’s a unique index on the CorrelationId column. You couldn’t have 2 different-typed sagas with the same value in the CorrelationId, which is really just another way to say my previosu bullet.

Is there a problem with keeping them separate? It’s better for performance and just logical separation.

If the saga classes OR saga data classes are different, you should keep them separate.

Didn’t see this was replied (spam filtered).
Basically when the three started they were implemented as transaction scripts so had customized logic in their implementation (don’t shoot me, I am here to clean things up). At this point they’re all identical logics using the same timeout messages and the identical method calls on the concrete classes performing the real logic. The differences are now fully encapsulated via polymorphic implementation. That’s really the source of the question.

Some quick confirmation actually shows that doing this results in each saga type getting called for the single timeout message (which actually makes a whole lot of sense now that we think about it…each saga technically maps to the data). Was interesting to see but a total “yeah…this is cogent behavior” moment. So learning point was partial migrations are no no-do it all or leave it be, which is essentially your point.