Add the reset_follower management command

[bibz]

Add a new Django management command, reset_follower, that can manually reset the tracking states of a follower (i.e. a ProcessApplication instance). The idea for the follower is to replay the whole history next time it is (manually) synchronised.

Note that this command does not interact with a running system, see the command sync_followers to nudge the system in catching up with the upstream apps.

---

@johnbywater This is the change I mentioned last week. I did not make any more changes to it but I think it's worth pushing now to open up the discussion (or let me know if you'd rather discuss in an issue thread first).

TODO:

• [ ] Document the command in README
• [ ] Support different databases (Django's using)

Open questions:

1. edit: no need. We could make the logic a bit more complicated if we locate the system runner to e.g. list all existing process applications, not only the ones with a state stored in the DB. I didn't think it was worth the complexity.

[johnbywater]

Thanks for doing this.

It all looks very neat and tidy, and useful!

The only thought I have, which I'm sure you have thought about already, is that in some cases deleting the tracking records, without also deleting the consequential state of processing the events that have been tracked, might lead to a state in which the events cannot be reprocessed. For example, if a "created" event has been processed by inserting a record, coded under the assumption that there isn't already a record, and attempting to insert such a record twice causes an integrity error.

Regarding your question: it makes good sense to deal with the database records, since if there are no records for a particular application name, then there are no recorded to delete, and locating the system runner in all cases is most likely going to be a tricky business?

Please carry on with this. I like it.

[bibz]

The only thought I have, which I'm sure you have thought about already, is that in some cases deleting the tracking records, without also deleting the consequential state of processing the events that have been tracked, might lead to a state in which the events cannot be reprocessed.

This is entirely correct, and that is an important point the documentation should not miss. Arguably the command output should also state it (and maybe offer a confirmation prompt just in case?)

For example, if a "created" event has been processed by inserting a record, coded under the assumption that there isn't already a record, and attempting to insert such a record twice causes an integrity error.

The first iteration I explored for this command was actually expecting the ProcessApplication to expose either a Django model name to purge directly, or provide a specific hook to be called as the records were cleaned-up.

I do use an added "reset method" in my own examples to prepare the ORM models when the ProcessApplication gets the Created event of a specific aggregate.

I will dig into supporting an additional (optional!*) protocol that offers a reset hook, think something like:

class ResetableFollower(Protocol):
    def on_reset(cls):
        ...

*: I feel quite strongly against name-squatting a method name unless it has been explicitly configured.

[bibz]

Updated the command tests for coverage (also output) and support for specifying which upstream app(s) to reset the tracking states of. I started documenting the command, and clearly need to illustrate better as this deals with advanced concepts. Still missing the protocol but I like that idea even more now.

[johnbywater]

Hey @bibz! Did you make any progress with this? Hope all is well with you :)

[bibz]

Hi @johnbywater! Sorry for the long silence I was busy elsewhere. As you can imagine, this went off my radar. I'll see if I can resume/wrap up soon or else it's going to be abandoned.

[johnbywater]

No worries @bibz! Thanks for replying. More than happy to have a meeting about it, if you think that would help.