Open xhafan opened 2 weeks ago
Hi @xhafan , thanks for your PR!
I'm reluctant to merge your PR as it is, because it's a subly, but clearly breaking change – e.g. consider what would happen if someone out there actually relied on the fact that incrementing the version number would make the saga data incompatible with previously serialized instances.
Having it as a pluggable strategy is definitely the correct way to solve this.
Would it be possible for you to crank it up a notch and port the ISagaTypeNamingStrategy
to the Rebus.PostgreSql repo too? 🙂
Hi @mookid8000 , shouldn't than ISagaTypeNamingStrategy
be part of the core Rebus library instead of copying this from one Rebus persistence sub-library to another?
@Buthrakaur That has been considered before, but the thing is that not all saga persisters need such a thing... even though it wouldn't hurt anything if it was part of core Rebus, it just wouldn't be used e.g. for MongoDB
I have a long running saga, with
saga_type
DB field containing an assembly version, example value:Core.Rebuses.SagaCommandData``1[[.Core.Features.Commands.SomeCommand, Core, Version=2.0.0.4195, Culture=neutral, PublicKeyToken=null]]
. There is a deployment during a long running saga, the assembly version changes, and it can no longer find the saga, I can see the messageCould not find existing saga data for message...
in the output.I was able to hack-fix it by removing the version from the
saga-type
, the value above would become:Core.Rebuses.SagaCommandData``1[[.Core.Features.Commands.SomeCommand, Core, Culture=neutral, PublicKeyToken=null]]
. That works for me.I can see
Rebus.SqlServer
containsISagaTypeNamingStrategy
, which looks like a solution for this issue. Unfortunately is does not exist inRebus.PostgreSql
.