`Follower(Application)` does not call `self.construct_mapper()` about eventsourcing

[johnbywater]

Hi @wapiflapi thanks for noticing and looking into this issue, and describing it so well.

Sorry for the delay in responding. I was just away on an extended summer break. I'm back now.

The solution you propose, of passing in the mapper class, seems good to me. It's a very simple fix, so long as all the applications are using the same type of mapper. The example doesn't really go as far as you have taken this.

I suppose if we wanted to support applications using different mapper classes, then we could specify the mapper classes as topics in the environment. And then have the factory resolving the topics to mapper classes. With the solution you provided as the default, where they all use the same class.

I've just made the change you suggested in the code, and everything seems to work okay! I will release a new version with this small change, and think about supporting different mapper classes in future.

[wapiflapi]

@johnbywater if using self.construct_mapper() in the Follower(Application) seems to you to be the right thing to do, I'd be happy to send a PR your way.

[wapiflapi]

While writing a fix for this on my Application inheriting from ProcessApplication I came up with:

class MyApplication(ProcessApplication):

    # Fixing a bug (?) in eventsourcing.
    def follow(self, name: str, log: NotificationLog) -> None:
        """
        Constructs a notification log reader and a mapper for
        the named application, and adds them to its collections
        of readers and mappers.
        """
        assert isinstance(self.recorder, ProcessRecorder)
        reader = NotificationLogReader(log, section_size=self.pull_section_size)
        env = self.construct_env(name, self.env)
        factory = self.construct_factory(env)
        mapper = factory.mapper(self.construct_transcoder(), type(self.mapper))
        self.readers[name] = reader
        self.mappers[name] = mapper

The important line is:

        mapper = factory.mapper(self.construct_transcoder(), type(self.mapper))

That might be somewhat cleaner, since it still uses the factory that is built for the env related to name, instead of our own.

To be honnest I don't understand enough about the implications of this to have an opinion on if this is safe or not but ...

[johnbywater]

Actually, MAPPER_TOPIC, CIPHER_TOPIC and COMRESSOR_TOPIC are defined but only CIPHER_TOPIC and COMPRESSOR_TOPIC are used. So I guess I was thinking (in 2021) to implement this but didn't get around to it. I think it would be quite easy to implement support for MAPPER_TOPIC and also TRANSCODER_TOPIC, along the same lines, that is to read the environment and resolve the topic if defined and otherwise use the default or given class, so that different applications can use different types of these things and still work together in a system.

[johnbywater]

Changes above released as v9.2.21:
https://pypi.org/project/eventsourcing/9.2.21/
https://eventsourcing.readthedocs.io/en/stable/topics/release_notes.html#version-9-2-21-released-13-oct-2023