Strict namespace resolution policy for events

[vzakanj]

Currently Marten uses the event type inferred from the event record/class to know the CLR type of the event when deserializing.
The default strategy of inferring the type (stored in Marten event db) is to snake_case the event class/record name without taking the fully qualified type name into consideration (documentation on the type column here https://martendb.io/events/storage.html#database-tables).

This can cause collisions when having same event type names in different namespaces, which leads to events being deserialized with the wrong type and causing the aggregates not to process them correctly.
The only way to handle this now is to use event type name mapping for each of the events (https://martendb.io/events/versioning.html#event-type-name-mapping) which can get tedious pretty fast, or rename the events to prevent the collisions.

The reason for this issue is to propose enabling a mode/switch which enables using the fully qualified type name of the event during resolution, which can help eliminate a whole class of potential problems related to event naming.

[jeremydmiller]

To be clear, this needs to be an opt in strategy and not change the default behavior. The current behavior you see was done purposely to make it "softer" to move event types around within a codebase. While the proposed alternative helps get around disambiguating event type names in certain project naming conventions, it also has the negative impact of making the system as a whole a little more brittle for future changes

[oskardudycz]

@vzakanj, I'll try to work on that, maybe I'll be able to include that in v6.

[krmapowel]

I do believe that this could be preferred configuration when creating new project. We've had situation when the same name of the event has been propagated to two or three different aggregates, and it took us a long time to figure out that it picked different type when deserialising and projecting.
Generally, having some kind of validation that you don't have two of the same event names in your system, would also be nice.

[jeremydmiller]

Again folks, we cannot make this the default without breaking a whole lot of existing users, and I disagree with making this the default anyway. I appreciate that this has been harmful for some subset of users, but we're not breaking every one else.

[jeremydmiller]

This is going to take breaking API changes in that static GetEventTypeName() method that's public. I'm doing the push this to V7 dance again