-
Notifications
You must be signed in to change notification settings - Fork 617
Persistence of projections with composite properties #2451
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
Thanks for reporting this. |
I've hit this problem as well, composite properties are not saving when using |
@meistermeier Just encountered this problem. We use CompositeProperty with and without a converter, and both scenarios are affected. |
Thanks everyone for reporting this. It will be fixed from 6.1 onwards. |
The changes defers the decomposition of the property into single values as late as possible, so that property filter can be left unchanged but now works on the actual attribute names. This fixes #2451.
The changes defers the decomposition of the property into single values as late as possible, so that property filter can be left unchanged but now works on the actual attribute names. This fixes #2451.
Domain attributes can be renamed using the `@Property` annotation when being mapped to and read from graph properties. That renaming must also happening when using projections. As with #2451 in 582fd7d this is kind of a problem with the existing filter mechanism that works after the stack has dealt with the actual properties. After all properties and paths are computed, they will be translated as late as possible before checked for inclusions: - When writing just before it is checked whether to add them to the properties parameter or not - When reading after they have been map-projected from the database into the result set but before they are checked for inclusions. Also addressed here is the a workaround for writes: In case a user had an interface based projection and used the graph property name as accessor, a write would succeed, however a read would fail. A property accessor has now been registered with the default projection factory that translates a failure to access an entity property (attribute) once. This fixes #2371.
Domain attributes can be renamed using the `@Property` annotation when being mapped to and read from graph properties. That renaming must also happening when using projections. As with #2451 in 582fd7d this is kind of a problem with the existing filter mechanism that works after the stack has dealt with the actual properties. After all properties and paths are computed, they will be translated as late as possible before checked for inclusions: - When writing just before it is checked whether to add them to the properties parameter or not - When reading after they have been map-projected from the database into the result set but before they are checked for inclusions. Also addressed here is the a workaround for writes: In case a user had an interface based projection and used the graph property name as accessor, a write would succeed, however a read would fail. A property accessor has now been registered with the default projection factory that translates a failure to access an entity property (attribute) once. This fixes #2371.
Domain attributes can be renamed using the `@Property` annotation when being mapped to and read from graph properties. That renaming must also happening when using projections. As with #2451 in 582fd7d this is kind of a problem with the existing filter mechanism that works after the stack has dealt with the actual properties. After all properties and paths are computed, they will be translated as late as possible before checked for inclusions: - When writing just before it is checked whether to add them to the properties parameter or not - When reading after they have been map-projected from the database into the result set but before they are checked for inclusions. Also addressed here is the a workaround for writes: In case a user had an interface based projection and used the graph property name as accessor, a write would succeed, however a read would fail. A property accessor has now been registered with the default projection factory that translates a failure to access an entity property (attribute) once. This fixes #2371.
The changes defers the decomposition of the property into single values as late as possible, so that property filter can be left unchanged but now works on the actual attribute names. This fixes #2451.
Domain attributes can be renamed using the `@Property` annotation when being mapped to and read from graph properties. That renaming must also happening when using projections. As with #2451 in 582fd7d this is kind of a problem with the existing filter mechanism that works after the stack has dealt with the actual properties. After all properties and paths are computed, they will be translated as late as possible before checked for inclusions: - When writing just before it is checked whether to add them to the properties parameter or not - When reading after they have been map-projected from the database into the result set but before they are checked for inclusions. Also addressed here is the a workaround for writes: In case a user had an interface based projection and used the graph property name as accessor, a write would succeed, however a read would fail. A property accessor has now been registered with the default projection factory that translates a failure to access an entity property (attribute) once. This fixes #2371. # Conflicts: # src/test/java/org/springframework/data/neo4j/integration/reactive/ReactiveProjectionIT.java
Hello,
I'm trying to use persistence of projections on an entity defining a composite property, but the property is not saved.
I'm using SDN 6.2.0.
Here is my testcase:
Unit test:
The code is available in this repository: https://github.com/gonzalad/sdn6-tests/blob/projection-persist-composite-properties/src/test/java/com/example/sdn6/Sdn6Test.java (it relies on testcontainers: no special setup for neo4j db required)
Thanks,
N.B. the issue seems to be related to TemplateSupport.createAndApplyPropertyFilter which gets additionalFields.key1 in the NAME_OF_PROPERTIES_PARAM parameter and tries to compare it with the composite property additionalFields
The text was updated successfully, but these errors were encountered: