-
Notifications
You must be signed in to change notification settings - Fork 192
AfterSaveEvent is never triggered #1074
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Can be done after #955 maybeCallAfterSave() should be added to Reactive/CouchbaseTemplate and called from applyUpdatedCas() which is called from ReactiveInsert/Upsert/Replace one(). maybeCallBeforeSave() can be added and maybe called from the same place as maybeCallAfterConvert(). Or maybe the two could be called on their own in the Mono in the one() method. |
Is there any update on this issue? We are getting the same issue on every event (onAfterDelete, onAfterSave, onApplicationEvent, onBeforeDelete, onBeforeConvert, onAfterSave). Thanks |
The prerequisite issue (#955) has been merged, so this can proceed. |
Thank you @mikereiche, is there a defined timeline for releasing this feature? |
Working on it now. |
1) the previous change (#955) to CouchbaseAuditingRegister intended to register AuditingEntityCallback instead of AuditingEventListener but only changed the name that AuditingEventListener was registered with. Since AuditingEventListener does exactly the same thing as AuditingEntityCallback, it behaved as those AuditingEntityCallback was being used. 2) It seems that the two mechanisms - EntityCallback and EventListener both do more-or-less the same thing. I'm not sure why there are two mechanisms to do the same thing. 3) Although the ReactiveAuditingEntityCallback mechanism is triggered only for reactive operations and the non-reactive AuditingEntityCallback is triggered only for non-reactive operations, the events are triggered for both. Since there was a desire to have distinct callbacks for reactive/non-reactive operations, I also made distinct events for reactive/non-reactive operations. However both the reactive and non-reactive event mechanisms are triggered for either reactive and non-reactive operations, so it is necessary for the mechanism to determine if it should act on the event. 4) Although there is an AbstractCouchbaseEventListener that is extended by LoggingEventListener and ValidatingEventListener, AuditingEventListener does not extend it (maybe it should). Closes #1074.
1) the previous change (#955) to CouchbaseAuditingRegister intended to register AuditingEntityCallback instead of AuditingEventListener but only changed the name that AuditingEventListener was registered with. Since AuditingEventListener does exactly the same thing as AuditingEntityCallback, it behaved as those AuditingEntityCallback was being used. 2) It seems that the two mechanisms - EntityCallback and EventListener both do more-or-less the same thing. I'm not sure why there are two mechanisms to do the same thing. 3) Although the ReactiveAuditingEntityCallback mechanism is triggered only for reactive operations and the non-reactive AuditingEntityCallback is triggered only for non-reactive operations, the events are triggered for both. Since there was a desire to have distinct callbacks for reactive/non-reactive operations, I also made distinct events for reactive/non-reactive operations. However both the reactive and non-reactive event mechanisms are triggered for either reactive and non-reactive operations, so it is necessary for the mechanism to determine if it should act on the event. 4) Although there is an AbstractCouchbaseEventListener that is extended by LoggingEventListener and ValidatingEventListener, AuditingEventListener does not extend it (maybe it should). Closes #1074.
1) the previous change (#955) to CouchbaseAuditingRegister intended to register AuditingEntityCallback instead of AuditingEventListener but only changed the name that AuditingEventListener was registered with. Since AuditingEventListener does exactly the same thing as AuditingEntityCallback, it behaved as those AuditingEntityCallback was being used. 2) The two mechanisms - EntityCallback and EventListener both do more-or-less the same thing. EventListener is intendended to be read-only, therefore EntityCallback is necessary and should be used for modifying operations such as markAudited which modifies @createdby, @CreatedDate, @LastModifiedBy, @LostModifiedDate. Eventually EventListener will be deprecated. 3) Although the ReactiveAuditingEntityCallback mechanism is triggered only for reactive operations and the non-reactive AuditingEntityCallback is triggered only for non-reactive operations, the events are triggered for both. Since there was a desire to have distinct callbacks for reactive/non-reactive operations, I also made distinct events for reactive/non-reactive operations. However both the reactive and non-reactive event mechanisms are triggered for either reactive and non-reactive operations, so it is necessary for the mechanism to determine if it should act on the event. 4) Although there is an AbstractCouchbaseEventListener that is extended by LoggingEventListener and ValidatingEventListener, AuditingEventListener does not extend it (maybe it should). Closes #1074.
1) the previous change (#955) to CouchbaseAuditingRegister intended to register AuditingEntityCallback instead of AuditingEventListener but only changed the name that AuditingEventListener was registered with. Since AuditingEventListener does exactly the same thing as AuditingEntityCallback, it behaved as those AuditingEntityCallback was being used. 2) The two mechanisms - EntityCallback and EventListener both do more-or-less the same thing. EventListener is intendended to be read-only, therefore EntityCallback is necessary and should be used for modifying operations such as markAudited which modifies @createdby, @CreatedDate, @LastModifiedBy, @LostModifiedDate. Eventually EventListener will be deprecated. 3) Although the ReactiveAuditingEntityCallback mechanism is triggered only for reactive operations and the non-reactive AuditingEntityCallback is triggered only for non-reactive operations, the events are triggered for both. Since there was a desire to have distinct callbacks for reactive/non-reactive operations, I also made distinct events for reactive/non-reactive operations. However both the reactive and non-reactive event mechanisms are triggered for either reactive and non-reactive operations, so it is necessary for the mechanism to determine if it should act on the event. 4) Although there is an AbstractCouchbaseEventListener that is extended by LoggingEventListener and ValidatingEventListener, AuditingEventListener does not extend it (maybe it should). Closes #1074.
1) the previous change (#955) to CouchbaseAuditingRegister intended to register AuditingEntityCallback instead of AuditingEventListener but only changed the name that AuditingEventListener was registered with. Since AuditingEventListener does exactly the same thing as AuditingEntityCallback, it behaved as those AuditingEntityCallback was being used. 2) The two mechanisms - EntityCallback and EventListener both do more-or-less the same thing. EventListener is intendended to be read-only, therefore EntityCallback is necessary and should be used for modifying operations such as markAudited which modifies @createdby, @CreatedDate, @LastModifiedBy, @LostModifiedDate. Eventually EventListener will be deprecated. 3) Although there is an AbstractCouchbaseEventListener that is extended by LoggingEventListener and ValidatingEventListener, AuditingEventListener does not extend it (maybe it should). Closes #1074.
1) the previous change (#955) to CouchbaseAuditingRegister intended to register AuditingEntityCallback instead of AuditingEventListener but only changed the name that AuditingEventListener was registered with. Since AuditingEventListener does exactly the same thing as AuditingEntityCallback, it behaved as those AuditingEntityCallback was being used. 2) It seems that the two mechanisms - EntityCallback and EventListener both do more-or-less the same thing. I'm not sure why there are two mechanisms to do the same thing. 3) Although the ReactiveAuditingEntityCallback mechanism is triggered only for reactive operations and the non-reactive AuditingEntityCallback is triggered only for non-reactive operations, the events are triggered for both. Since there was a desire to have distinct callbacks for reactive/non-reactive operations, I also made distinct events for reactive/non-reactive operations. However both the reactive and non-reactive event mechanisms are triggered for either reactive and non-reactive operations, so it is necessary for the mechanism to determine if it should act on the event. 4) Although there is an AbstractCouchbaseEventListener that is extended by LoggingEventListener and ValidatingEventListener, AuditingEventListener does not extend it (maybe it should). Closes #1074.
1) the previous change (#955) to CouchbaseAuditingRegister intended to register AuditingEntityCallback instead of AuditingEventListener but only changed the name that AuditingEventListener was registered with. Since AuditingEventListener does exactly the same thing as AuditingEntityCallback, it behaved as those AuditingEntityCallback was being used. 2) It seems that the two mechanisms - EntityCallback and EventListener both do more-or-less the same thing. I'm not sure why there are two mechanisms to do the same thing. 3) Although the ReactiveAuditingEntityCallback mechanism is triggered only for reactive operations and the non-reactive AuditingEntityCallback is triggered only for non-reactive operations, the events are triggered for both. Since there was a desire to have distinct callbacks for reactive/non-reactive operations, I also made distinct events for reactive/non-reactive operations. However both the reactive and non-reactive event mechanisms are triggered for either reactive and non-reactive operations, so it is necessary for the mechanism to determine if it should act on the event. 4) Although there is an AbstractCouchbaseEventListener that is extended by LoggingEventListener and ValidatingEventListener, AuditingEventListener does not extend it (maybe it should). Closes #1074. Co-authored-by: mikereiche <[email protected]>
1) the previous change (#955) to CouchbaseAuditingRegister intended to register AuditingEntityCallback instead of AuditingEventListener but only changed the name that AuditingEventListener was registered with. Since AuditingEventListener does exactly the same thing as AuditingEntityCallback, it behaved as those AuditingEntityCallback was being used. 2) It seems that the two mechanisms - EntityCallback and EventListener both do more-or-less the same thing. I'm not sure why there are two mechanisms to do the same thing. 3) Although the ReactiveAuditingEntityCallback mechanism is triggered only for reactive operations and the non-reactive AuditingEntityCallback is triggered only for non-reactive operations, the events are triggered for both. Since there was a desire to have distinct callbacks for reactive/non-reactive operations, I also made distinct events for reactive/non-reactive operations. However both the reactive and non-reactive event mechanisms are triggered for either reactive and non-reactive operations, so it is necessary for the mechanism to determine if it should act on the event. 4) Although there is an AbstractCouchbaseEventListener that is extended by LoggingEventListener and ValidatingEventListener, AuditingEventListener does not extend it (maybe it should). Closes #1074. Co-authored-by: mikereiche <[email protected]>
AbstractCouchbaseEventListener#onAfterSave
is never calledThis worked in Spring Data Couchbase 3.x
The text was updated successfully, but these errors were encountered: