You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Process Managers don't serialize their state like anything else. This breaks some assumptions about how the serializer and type providers interact. It happens to work with the default config, but breaks with almost any custom TypeProvider implementation.
Description
For aggregates, the source_type for serializing snapshots is taken from the TypeProviderhere.
For events, the source_type for serializing snapshots is taken from the TypeProviderhere.
This is all well and good. However, for process managers the source_type for serializing snapshots is hardcoded to use the module name here.
That becomes problematic when you're using a custom TypeProvider together with the default JsonSerializer implementation. That's because it tries to look up the type from the TypeProviderhere.
So long as you don't use the JSON serializer or don't use a custom TypeProvider, that works fine. When you use both, you get some really exciting errors in serialization.
Recommended Fix
Use the TypeProvider to resolve the type for serializing process managers.
I don't think this will break any existing installations as they're either not encountering it, currently broken anyways, or have worked around it in a way that won't break.
Our Current Issue
We're using OnePiece.Commanded.TypeProvider (see here) to combine type providers from all of our domains. It lets us explicitly specify the names used to reference types. We use the prefix feature as well, which automatically adds a prefix to the names for all of the registered types in a given individual domain.
This is nice because it decouples the database type names from actual module names and, consequently, how our code is structured. Since events are forever, we consider this a pretty big deal. There's no cleaning up the naming later without some database surgery that we'd prefer not to do.
This bug forces us to not register a "decoupled" name and to not use the prefix feature for any process manager. Using prefixes also changes the name even if we use the module name, so we end up having them all collecting in our top-level type provider.
So they cannot go where we normally put them, they cannot be named how we normally name them, and they cannot be decoupled from the module name. As you might imagine, some nervousness about even using process managers at all since we can't later rename modules like we can with aggregates and events.
The text was updated successfully, but these errors were encountered:
Summary
Process Managers don't serialize their state like anything else. This breaks some assumptions about how the serializer and type providers interact. It happens to work with the default config, but breaks with almost any custom
TypeProvider
implementation.Description
For aggregates, the
source_type
for serializing snapshots is taken from theTypeProvider
here.For events, the
source_type
for serializing snapshots is taken from theTypeProvider
here.This is all well and good. However, for process managers the
source_type
for serializing snapshots is hardcoded to use the module name here.That becomes problematic when you're using a custom
TypeProvider
together with the defaultJsonSerializer
implementation. That's because it tries to look up the type from theTypeProvider
here.So long as you don't use the JSON serializer or don't use a custom
TypeProvider
, that works fine. When you use both, you get some really exciting errors in serialization.Recommended Fix
Use the
TypeProvider
to resolve the type for serializing process managers.I don't think this will break any existing installations as they're either not encountering it, currently broken anyways, or have worked around it in a way that won't break.
Our Current Issue
We're using
OnePiece.Commanded.TypeProvider
(see here) to combine type providers from all of our domains. It lets us explicitly specify the names used to reference types. We use theprefix
feature as well, which automatically adds a prefix to the names for all of the registered types in a given individual domain.This is nice because it decouples the database type names from actual module names and, consequently, how our code is structured. Since events are forever, we consider this a pretty big deal. There's no cleaning up the naming later without some database surgery that we'd prefer not to do.
This bug forces us to not register a "decoupled" name and to not use the prefix feature for any process manager. Using prefixes also changes the name even if we use the module name, so we end up having them all collecting in our top-level type provider.
So they cannot go where we normally put them, they cannot be named how we normally name them, and they cannot be decoupled from the module name. As you might imagine, some nervousness about even using process managers at all since we can't later rename modules like we can with aggregates and events.
The text was updated successfully, but these errors were encountered: