Skip to content

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

Closed
gonzalad opened this issue Nov 24, 2021 · 4 comments
Closed

Persistence of projections with composite properties #2451

gonzalad opened this issue Nov 24, 2021 · 4 comments
Assignees
Labels
type: bug A general bug

Comments

@gonzalad
Copy link

gonzalad commented Nov 24, 2021

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:

@Node("Widget")
public class WidgetEntity {

    @GeneratedValue
    @Id
    private Long id;
    private String code;
    private String label;

    @CompositeProperty
    private Map<String, Object> additionalFields = new HashMap<>();

...
}
public interface WidgetProjection {

    String getCode();

    String getLabel();

    Map<String, Object> getAdditionalFields();
}

Unit test:

    @Test
    void testSaveAsWidgetProjectionWithCompositeProperty() {

        String code = "Window1";
        WidgetEntity window = repository.findByCode(code).orElseThrow();
        window.setLabel("changed");
        window.getAdditionalFields().put("key1", "value1");

        template.saveAs(window, WidgetProjection.class);

        window = repository.findByCode(code).orElseThrow();
        assertThat(window.getAdditionalFields()).hasSize(1); => this returns 0 !!
    }

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

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Nov 24, 2021
@meistermeier meistermeier added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged labels Nov 25, 2021
@meistermeier
Copy link
Collaborator

Thanks for reporting this.
I would link this to #2371 because as far as I understood what is happening, both issues are very close.

@surjitbhachu
Copy link

I've hit this problem as well, composite properties are not saving when using saveAs. Are there any workarounds to save these properties to the database?

@cberes
Copy link
Contributor

cberes commented Jan 28, 2022

@meistermeier Just encountered this problem. We use CompositeProperty with and without a converter, and both scenarios are affected.

@michael-simons michael-simons self-assigned this Jan 31, 2022
@michael-simons michael-simons added type: bug A general bug and removed type: enhancement A general enhancement labels Jan 31, 2022
@michael-simons
Copy link
Collaborator

Thanks everyone for reporting this. It will be fixed from 6.1 onwards.

@michael-simons michael-simons added this to the 6.1.9 (2021.0.9) milestone Jan 31, 2022
michael-simons added a commit that referenced this issue Jan 31, 2022
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.
michael-simons added a commit that referenced this issue Jan 31, 2022
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.
michael-simons added a commit that referenced this issue Jan 31, 2022
michael-simons added a commit that referenced this issue Feb 1, 2022
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.
michael-simons added a commit that referenced this issue Feb 1, 2022
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.
michael-simons added a commit that referenced this issue Feb 1, 2022
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.
michael-simons added a commit that referenced this issue Feb 1, 2022
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.
michael-simons added a commit that referenced this issue Feb 1, 2022
michael-simons added a commit that referenced this issue Feb 1, 2022
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
@michael-simons michael-simons mentioned this issue Jan 4, 2023
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug A general bug
Projects
None yet
Development

No branches or pull requests

6 participants