Remove beforePatch and afterPatch from FHIRPersistenceInterceptor interface
Is your feature request related to a problem? Please describe. Currently, the FHIRPersistenceInterceptor contains before and after methods for each interaction type, including PATCH.
However, in practice the beforePatch and afterPatch are basically always the same as beforeUpdate and afterUpdate. The one difference is that the FHIRPersistenceEvent for the patch interactions also includes the FHIRPatch constructed for this interaction.
Furthermore, at the persistence layer, there is no patch. The REST layer actually applies the patch and converts it into a "normal" update.
This is similar to the way our rest layer converts "create-on-update" interactions into normal "create" events (beforeCreate and afterCreate) rather than update events (beforeUpdate and afterUpdate).
Describe the solution you'd like Due to the similarities, I think we should remove the beforePatch and afterPatch methods from the interface. If someone really needs to know that a given update came from a patch, they can check for the patch on the event.
Describe alternatives you've considered Keep it as-is.
Acceptance Criteria
- GIVEN [a precondition] AND [another precondition] WHEN [test step] AND [test step] THEN [verification step] AND [verification step]
Additional context Because the interface includes a default "do nothing" implementation, its easy for implementers of this interface to miss the beforePatch and afterPatch options.
Suggestion to deprecate this in the next 5.x release (if there is one), prior to removal in 6.0
today fhir-notification issues a different event type for "update" vs "patch". i think we should consolidate there as well; updates that were performed via patch would still be normal 'update' events.