cancel
Showing results for 
Search instead for 
Did you mean: 

Head's Up! These forums are read-only. All users and content have migrated. Please join us at community.neo4j.com.

Using Repository with Interfaces in Boot 2.2+

Have used a NodeEntity interface for loading nodes using a custom findBy repository method and this is working fine with Spring Boot 2.1,

Have just tried using Boot 2.2 (and 2.3) and it now fails with:

Caused by: org.springframework.data.mapping.context.InvalidPersistentPropertyPath: No property 'name' found on interface com.example.interfacerepo.WorkCalendar! Did you mean: ?

Any ideas what I need to do to resolve this?

Entity interface:

@NodeEntity
public interface WorkCalendar {
    String getName();
}

Entity implementation:

@NodeEntity
@Getter
public class StandardWeekCalendar implements WorkCalendar {
    public static final String NAME = "Standard Working Week";
    private String name = NAME;
}

Repository:

@Repository
public interface WorkCalendarRepository extends Neo4jRepository<WorkCalendar, Long> {
    WorkCalendar findByName(String name);
}
3 REPLIES 3

I am sorry but I cannot tell you how to solve this with the current interfaces / classes.
Also I am wondering how this should have ever worked.
WorkCalendar does not specify any field named name as you want the finder method to work with. So the error makes a lot of sense. Spring Data cannot just accept the parameter but verifies the existence of a property named name.
I don't think that we did a lot of changes in this direction in SDN / Neo4j-OGM but I assume that this check that causes the problem is rooted in Spring Data commons.

@gerrit.meier Thanks for the response. Have fixed it by adding custom queries to the repo methods. Previously it must have been seeing the existence of the property based on getter defined in the interface.

Would a better approach (from a Neo4J perspective) be to use a base class (instead of interface)?

@NodeEntity
@Getter
public abstract class WorkCalendar {
    private String name;
}

At least you would get the name property again available for a:
WorkCalendar findByName(String name);
and won't have to write custom queries.