Spring Data Neo4j RX @RelationshipProperties List problem

Drivers & Stacks Spring Data Neo4j & Neo4j-OGM
1

So my current model of Person contains

	@Relationship(type = PROVIDES_SUPPORT, direction = INCOMING)
	private Map<Person, List<SupportRelationship>> supporters = new HashMap<>();

Those are the people that "support" the current Person (let's say Angel) by different type of ways. The SupportRelationship contains that type as a property, start date and an end date. The thing is the same Person can provide different types of Support to Angel, that's why it maps a Person to a List of Support.

Seems like I am not able to achieve that, because of the method createAssociation() inside of the class DefaultNeo4jPersistentProperty:

        if (this.hasActualTypeAnnotation(RelationshipProperties.class)) {
            obverseOwner = (Neo4jPersistentEntity)this.mappingContext.getPersistentEntity(this.getComponentType());
        } else {
            obverseOwner = (Neo4jPersistentEntity)this.mappingContext.getPersistentEntity(this.getAssociationTargetType());
        }

It goes straight to the else statement, where this.getAssociationTargetType() is null. After that the constructor inside ClassTypeInformation:

    public static <S> ClassTypeInformation<S> from(Class<S> type) {
        Assert.notNull(type, "Type must not be null!");
        return (ClassTypeInformation)CACHE.computeIfAbsent(type, ClassTypeInformation::new);
    }

catches the null type and throws an Exception, resulting in a failed build.

Is there a better way to achieve what I want and am I missing something? Seems like the thing I'm trying to do is not possible at the current state, so is there a better way or a workaround to it?
Really appreciate the help.

2

You are right with your observation that this is a missing feature at the moment.
Your (simple) example is really helpful to have a use-case at hand when implementing this.
Currently it seems like we will have to change the relationship properties modelling in the near future because it brings also some problems for derived queries in its current form with it, so I will definitely take your input also for planning the new modelling.

In the meantime I cannot provide you a solution that would make sense for your domain besides using different relationship types and create multiple @Relationships.

1 Like
3

Thanks for the answer and best of luck on future releases :slight_smile: