Renamed properties are not included during writes and not projected during reads.

[meistermeier]

Inspired by https://stackoverflow.com/questions/68938823/sdn6-projection-interfaces-with-property-mapping
we should at least check if it is possible to create a connection between the defined method in a projection to the field in the domain object.

Reproducer / play along project: https://github.com/meistermeier/neo4j-issues-examples/tree/master/so-68938823

[meistermeier]

First analysis (unfortunately no solution yet):
The problem roots in the current situation that we provide a list of parameters to the modifying query that is based on the metadata of the domain. At this moment there are only graph property names left. Filtering them with the java properties list does not work.

1. We could add the graph property names to the property filter constructs when starting the operation. But this won't work out of the box because the projection field detection is based on PropertyPaths. Adding the graph property names here would lead into an exception because those are invalid PropertyPaths.

2. There is the moment of creating PropertyFilter out of the provided PropertyPaths. At this point the MappingContext is missing to e.g. call getPersistentPropertyPath to get the property information needed. I personally would try to avoid throwing a MappingContext in there.

3. This is option has a broader impact: We should consider filtering the properties before invoking the binder function for write. Or pass the filter on to the function. This would avoid unnecessary conversion upfront. In 1 and 2 we create sets that filter the parameters list after the list got created.

I would like to investigate option 2 with an external "alternative property name provider" approach.

[meistermeier]

It seems that option 2 is a valid one and does not too much influence the existing code base or make it unnecessary complex.

[michael-simons]

I agree with option 1+2: Throwing in the renamed attributes at the moment when the dotPaths are created in 2 when we the entity is still available works. But it needed to be done in both reads and writes. I wanted to avoid another concept like the alternative naming function. We have too many call sites that are affect (6, actually, 3 for imperative and 3 for reactive).

Also I took care of keeping the workaround in the SO question working (actually made it work for reads, too).