Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Adds support for filtering out deleted events from queries #191
(description copied from #162 for context)
This PR introduces filtering of deleted events. To better understand why this is needed, we must understand the historical reasons for this and make some guesses about its evolution.
What follows is an assumption, I don't have all the knowledge of how the plugin architecture evolved. Therefore will try to outline here all the information I could collect and the assumptions I'm making.
Delete Journal Events
I guess that everybody agrees that an Event Sourcing application should not delete events. However, sometimes this may be needed (free up space) or required by law (currently flawed because of snapshoting and highest seq num issue, read further). So, this feature makes sense but has to be used with caution.
Physical or Logical Delete
Events can be physically or logically deleted. Logical deletion seems at first a very odd feature because it doesn't help at all in freeing up space nor does it fulfill legal regulations.
As far I can understand, the only reasons for logical deletions are:
Logical Deletes and Backward "awkward" Compatibility
The previous behavior was logical deletion with events being delivered on query side. This is very odd. Why one would perform a logical delete on the write-side and still consume the events on the read-side? If the events are still needed, one should not "delete" them.
This PR preserves this behavior. Logical deletes are enable by default and events are delivered when querying.
Physical deletes are now possible (see #161, thanks @dmi3zkm). However, as mentioned above, the last event is not physically delete because we need to be able to trace the highest seq num per persistent actor. Because of the logical deletion of latest event is an internal trick, we should treat it as a real delete, therefore they are not delivered on queries.
WellingR left a comment •
These changes look good (except for the small comments I had).
In case we decide to drop the logical deletion in the 4.0.0 version then we should probably include a deprecation warning somehow.
Places where we could log this warning
I guess the first of these options would be the best, since the startup logging is the logging that would be noticed first.
I want to merge this, however I see one last issue, the oracle test seems to be broken