search

rebus-org / Rebus

:bus: Simple and lean service bus implementation for .NET
https://mookid.dk/category/rebus
Other
2.27k stars 355 forks source link

Saga persisters must be able to store several saga types #92

Closed mookid8000 closed 12 years ago

mookid8000 commented 12 years ago

SqlServerSagaPersister and MongoDbSagaPersister both need the ability to store sagas of different types.

In order to do this, either a) persist the saga type as part of the ID and correlation ID, or b) make it possible for the persisters to store sagas in tables/collections dependending on the saga type.

The RavenDbSagaPersister doesn't seem to have this issue... or does it?

asgerhallas commented 12 years ago

The ´RavenDbSagaPersister´ supports that. Raven automatically names the collection after the stored types name.

Off of the top I my head i'd say that option b sounds most understandable to me...

asgerhallas commented 12 years ago

I've tried to create a failing test for this. But I failed... not the test. Not for any of the persisters. Are there anything I've overlooked, or does this indeed work?

asgerhallas commented 12 years ago

The SqlServerSagaPersister will of course create a lot of only partially used columns in the index table. I don't know how Mongo behaves when indexing differing types in the same collection.

mookid8000 commented 12 years ago

You can make it fail if you have two saga types, and you persist an instance of each where - by coincidende - there happens to be a correlation property with the same name and the same value.

I've written a test that makes it evident - the fixture is called TestSagaPersisterCorrelationIdUniqueConstraint

mookid8000 commented 12 years ago

No need to implement anything for RavenDbSagaPersister.

MongoDbSagaPersister has been augmented with the ability to have collection names configured individually for each saga data type, or alternatively a more "conventional" approach can be selected with the AllowAutomaticSagaCollectionNames option.

SqlServerSagaPersister still uses the same two tables, but the index table has had an extra column added that specifies the saga data type name. This way, there will be no issues with duplicate entries in the index even though two saga data types might have a property with the same name and the same value.