FetchForWriting should assert that it is only usable for single stream projections about marten HOT 4 OPEN

"Is my understanding correct that the new FetchForWriting API is currently not usable for MultiStreamProjection cases?"

Correct. It's only usable for single stream projections. Its whole point was for "write" models in command handlers. There's no easy way you could adapt that for multi-stream projections if you think about it for a bit.

from marten.

Improve the docs and make FetchForWriting() do an assertion if you try to use it w/ a multi stream projection

from marten.

@jeremydmiller

I understand that for using them as write models this does not make much sense (and goes against certain DDD principles). but in this particular cases I was actually trying to create a read-model. I hoped this could benefit from the cool zero-downtime versioned mechanics for FetchForWriting described here https://jeremydmiller.com/2024/03/05/marten-7-makes-write-model-projections-super/

I'm not that familiar with the actual implementation, but I feel like it must be possible to have a similar mechanic for multiple source streams. But this is ofcourse talking about the solution, not the actual problem. I'm mainly trying to find a way to avoid the situation where we have to take down all our pods when deploying a new version in order to rebuild our multi-stream projections instead of our regular Blue/Green deployments. Or even worse: a developer forgetting to rebuild a business-critical projection leading to incorrect results being passed down to the next business unit.

from marten.

@CptWesley The problem is that there's no easy way for Marten to reason about exactly what the events are for a multi-stream projection. Plus FetchForWriting() also does some locking work on the stream table. It's very much purpose written for "write" models on a single stream at a time.

What you're trying to do is definitely an interesting use case suggestion, but you'd need a brand new API and mechanism for doing that.

from marten.