-
Notifications
You must be signed in to change notification settings - Fork 41.2k
Persistent and RelationshipProperties-annotated types are not scanned with Spring Data Neo4j #24239
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@meistermeier thanks for the PR. While I can see adding Persistent
to be generally useful and consistent, I think that adding RelationshipProperties
calls for adding a test that showcases why that is necessary. We may need to rephrase the issue so that the user-facing change is clearer.
Thanks for the quick response @snicoll . |
3545c45
to
effc76d
Compare
effc76d
to
ac1c445
Compare
Unfortunately how I thought the change could be done better was not successful. So I stick now to the initial solution and added the tests to ensure that only those classes with annotations that mark explicitly entities ( |
Thanks for the follow-up.
I am not sure I got that. Does adding this type fixes a bug? And if so, can we please have a test that showcases that? The tests that were added merely checked that scanning works as expect but that's not really explaining why adding that type is necessary. |
In a scenario that enforces the Spring Data infrastructure to go into strict mode, implicit registration of entities are not possible (throws exception on later registration). Besides being not a prominent entity in the broader API sense, technically a |
To align with the other store modules, I added the
Persistent
type to the initial scan list. We already added this in SDN itself as a supported type.Also the
RelationshipProperties
type got added to this list, because the loading of those entities would fail if we are running in Spring Data's strict mode (e.g. multi store modules) and they would get requested during runtime. In contrast to the startup phase when this method gets called.