danielmarbach
commented
2 years ago @kylejuliandev thanks for reaching out. Custom finders is something that is a quite hard to support across the board. Some of the problems of custom finders are highlighted on our documentation page.
When using custom saga finders, users are expected to configure any additional indexes needed to handle concurrent access to saga instances properly using the tooling of the selected storage engine. Due to this constraint, not all persisters will be able to support custom saga finders to the same degree.
Currently, only NHibernate and SqlPersistence properly support custom saga finders. CosmosDB is another one of the persisters that doesn't support them at this stage. Our concerns were as you mentioned around the resource consumption when querying, but also giving a bulletproof tool that makes sure the optimistic or pessimistic locking needs of the saga persister are fulfilled.
Like you mentioned, would it be possible for you to for example add a behavior to the incoming pipeline that combines the two headers into one so that the saga mapping can pick up that single "synthetic" header?
I will add it as a feature request to the backlog for now.
Hi,
It would be great to have support for Custom Saga finders for the CosmosDB Persistence package. It appears as though we do not support it, see SagaIdGenerator.
I ran into this issue while I was building a more complicated look-up scenario that involved correlating two message headers, like
[Type]_[Id]. I can work around this by opting to create a new header with this value, allowing me to use the more conventional look up mechanisms under ConfigureHowToFindSaga.I'm anticipating that this was intentional, given the resource consumption concerns when querying CosmosDB incorrectly (I.e. not within a single logical partition).
Many thanks,