EventAdapters Persistence review based on changes

gistfile1.txt

Premise:

We need an extra manifest column for EventAdapters. Because SerializerWithStringManifest type serializers are not compatible.


Findings:

EventAdapters are registered via an ActorSystem extension. And they are utilised based on an type -> adapter mapper. Which means if you want to utilise them you have to provide a mapping for the message type you want to use it on. Same concept as how serialization-bindings work.

EventAdapters are layered in the persistence system. Like a layer of a sandwich :P.

On the read side. Data is read from the store, deserialized, constructed into a Persistentrepresentation after which its payload and manifest data is fed into the EventAdapters subsystem. 
Which may or may not (depending on if a specific adapter is configured and what it does) change the payload message before its delivered to the persistentactor. 

On the write side the opposite happens. In the PersistentActor a Persist command is given, signalling that a message needs to be stored.
The journal then passes the object through the EventAdapters layer, and uses its information to construct a PersistentMessage, which is subsequently handled by the Serialization system, and stored in the persistent store.

A EventAdapter may specify its own Manifest type to be used for the message its handling. This manifest will be passed along to the serialization subsystem before ending up in the persistent store.

In the case of SerializerWithStringManifest type serializes. They in turn can update the Manifest and thus override whatever is being fed into the serialization subsystem by the persistence system. 

Lets make a list of serializers which currently implement SerializerWithStringManifest:
- ClusterShardingMessageSerializer
- DistributedPubSubMessageSerializer
- ClusterClientMessageSerializer
- ClusterSingletonMessageSerializer

- MiscMessageSerializer

These are ALL serializer types which handle internal AKKA infrastructure messages. What they do is translating long type names like "akka.core.something.something.routing.something.reallyimportantPubSubAckMsg" to "PBACK" and provide a system for mapping those abreviations back to the correct type.

Conclusion. 

Unless you start mapping eventadapters to internal system message types. (which as far as i can tell from the docs its not a supported scenario). We are fine.
But in short. Yes EventAdapters that provide custom manifest information are NOT supported in combination with serializers that implement SerializerWithStringManifest.
This is not an issue, because as I have outlined, those type of serializers are only used for internal akka types. And not userspace types. For which EventAdapters are meant.

Sources:

WriteJournal.cs -> WriteJournalBase
    - AdaptFromJournal
    - AdaptToJournal
    
BatchingSqlJournal.cs
SqlJournal.cs
AsyncWriteJournal.cs