Introduce ValidatingEntityCallback and deprecate ValidatingMongoEventListener
#4910
Conversation
rfelgent
commented
Mar 2, 2025
•
rfelgent
commented
- You have read the Spring Data contribution guidelines.
- You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
- You submit test cases (unit or integration tests) that back your changes.
- You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).
spring-projects-issues
added
the
status: waiting-for-triage
| * JSR-303 dependant entities validator. | ||
| * <p> | ||
| * When it is registered as Spring component its automatically invoked | ||
| * after any {@link AbstractMongoEventListener} and before entities are saved in database. |
There was a problem hiding this comment.
@mp911de , I copied the documentation from ValidatingMongoEventListener and adjusted it for the ValidatingEntityCallback.
Is the statement regarding automatic invocation still valid?
|
|
||
| private static final Log LOG = LogFactory.getLog(ValidatingEntityCallback.class); | ||
|
|
||
| // TODO: create a validation handler (similar to "AuditingHandler") an reference it from "ValidatingMongoEventListener" and "ValidatingMongoEventListener" |
There was a problem hiding this comment.
personally, I could live with this implementation (and duplicate the validation code logic of ValidatingMongoEventListener)
| @Override | ||
| public Object onBeforeSave(Object entity, Document document, String collection) { | ||
|
|
||
| if (LOG.isDebugEnabled()) { |
There was a problem hiding this comment.
pls tell me, is "debug" or "trace" the appropriate choice for bean validation ?
mp911de
changed the title
ValidatingEntityCallback and deprecate ValidatingMongoEventListener
mp911de
added
type: enhancement
There was a problem hiding this comment.
Thanks a lot. For validation, we should also consider the reactive flow that should not throw exceptions but rather return Mono.error(e). I think it makes sense to extract a tiny superclass returning Set<ConstraintValitation> and let the callback and event listener reuse those bits. We could then get rid of logging in each component.
Admittedly, it's not much code, but a few concerns that we do not require in subclasses.
Also, we should deprecate the event listener and ideally find a place in the reference documentation to mention Bean Validation support.
Let me know how comfortable you are addressing these aspects and what guidance I can provide you with.
agreed. I will add a parent class and make
agreed, should the introduction of a reactive-based entity validor be part of this pull request or another one?
agreed, should this be part of this pull request or another one ? |
Signed-off-by: felgentraeger <rene.felgentraeger@gvl.de>
Signed-off-by: felgentraeger <rene.felgentraeger@gvl.de>
Signed-off-by: felgentraeger <rene.felgentraeger@gvl.de>
Signed-off-by: felgentraeger <rene.felgentraeger@gvl.de>
Signed-off-by: felgentraeger <rene.felgentraeger@gvl.de>
rfelgent
force-pushed
the
feature/gh-4901
branch
from
46051a6 to
c0e7bfb
Compare
|
Let's handle everything right here, no need to spread this enhancement over multiple tickets as these changes sum up nicely in a single logical change. |
|
Thank you for your contribution. That's merged and polished now. I extracted a few bits and tweaked the documentation slightly, adding a reactive callback variant. |
