Support domain events for deletions [DATACMNS-1663]

[spring-projects-issues]

Oliver Behncke opened DATACMNS-1663 and commented

When saving an entity in a CrudRepository, the events available in the method annotated with @DomainEvents are published.

 

However, when deleting an entity with the same repository, none of the events are published. Explicitly, in EventPublishingMethodInterceptor#invoke only methods starting with "save" are considered to trigger publishing of the events.

 

It would be nice, if the domain events would be published on delete, to avoid injecting the spring framework class ApplicationEventPublisher into the domain related code

---

Affects: 2.2.4 (Moore SR4)

Referenced from: pull request #436

8 votes, 5 watchers

[spring-projects-issues]

Oliver Drotbohm commented

That's merged for 2020.0.0

[kevinchan-rl]

hey guys I noticed deleteById also does not publish, should this be fixed?

[odrotbohm]

How would a deleteById(…) produce an event in the first place?

[amariik]

Wouldn't @PrePersist/PreRemove etc potentially trigger the creation of some events which should be published?

[odrotbohm]

That's a good point. I'll have to investigate, but from a quick glance, I think that only JPA currently supports entity-attached lifecycle callbacks. This means, that while adding deleteById(…) to the list of event publishing methods, there's still no way to let that trigger event publication in, for example, stores like MongoDB.

[odrotbohm]

I've investigated the support for deleteById(…) and have come to the conclusion that we cannot support this properly. The event publication mechanism relies on the aggregate instance(s) to be handed to the repository. Even if we assume that deleteById(…) loads these before deletion, the JPA specific lifecycle events fire deep down within the JPA implementation, and we cannot reasonably pick up the events created so deep down the call stack.

[amariik]

That is understandable. I think it would be a nice to have but not a must have. We only ran into this recently and switching to using the normal delete() was simple enough in our case. It was however surprising at first glance. I appreciate you digging into this.

[odrotbohm]

I guess we can still add a bit of clarification in the reference documentation.