Skip to content

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

Closed
aaronjwhiteside opened this issue Feb 4, 2021 · 5 comments · Fixed by #1142
Closed

AfterSaveEvent is never triggered #1074

aaronjwhiteside opened this issue Feb 4, 2021 · 5 comments · Fixed by #1142
Labels
type: regression A regression from a previous release

Comments

@aaronjwhiteside
Copy link
Contributor

AbstractCouchbaseEventListener#onAfterSave is never called

This worked in Spring Data Couchbase 3.x

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Feb 4, 2021
@mikereiche
Copy link
Collaborator

mikereiche commented Mar 24, 2021

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.

@mikereiche mikereiche added type: regression A regression from a previous release and removed status: waiting-for-triage An issue we've not yet triaged labels Mar 24, 2021
@ocortassa
Copy link

ocortassa commented May 21, 2021

Is there any update on this issue?

We are getting the same issue on every event (onAfterDelete, onAfterSave, onApplicationEvent, onBeforeDelete, onBeforeConvert, onAfterSave).

Thanks

@mikereiche
Copy link
Collaborator

The prerequisite issue (#955) has been merged, so this can proceed.

@ocortassa
Copy link

Thank you @mikereiche, is there a defined timeline for releasing this feature?

@mikereiche
Copy link
Collaborator

Working on it now.

mikereiche added a commit that referenced this issue May 28, 2021
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.
mikereiche added a commit that referenced this issue Jun 2, 2021
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.
mikereiche added a commit that referenced this issue Jun 8, 2021
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.
mikereiche added a commit that referenced this issue Jun 8, 2021
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.
mikereiche added a commit that referenced this issue Jun 10, 2021
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.
mikereiche added a commit that referenced this issue Jun 10, 2021
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.
mikereiche added a commit that referenced this issue Jun 10, 2021
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]>
mikereiche added a commit that referenced this issue Aug 9, 2021
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: regression A regression from a previous release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants