Allow interfaces in domain model hierarchies.

[hamidbm]

I have few Entity node classes (PurchaseEntity, PLIEntity, EntitlementSetEntity, EntitlementEntity, ...) and the server can only start if not more than one repository interface is defined. Currently I have one repository interface (PurchaseRepository), but when I add another repository (like EntitlementRepository for example for the entity Entitlement), the server cannot start and throws the following error:

Caused by: org.springframework.data.mapping.MappingException: The schema already contains a node description under the primary label PLI

Only the entity PLIEntity is annotated with @node("PLI"), the other entities have their own labels, but somehow SDN is thinking all entities are labeled with PLI label

Entities are like this:

@node("Purchase")
public class PurchaseEntity {...}

@node("PLI")
public class PLIEntity {...}

@node("Entitlement")
public class { ... }

etc...

[meistermeier]

I created an example from your description here: https://github.com/meistermeier/neo4j-issues-examples/tree/master/gh-2201
This starts up completely fine. Can you tell me the differences regarding mapping / entity definition that I have missed to reproduce your problem?

[hamidbm]

I think the issue is this: when you create a data model (a set of entities) and something is not well configured in one of the entities, SDN when trying to resolve and register the model, it makes another call to the same method again and the entity is found already registered and then it throws an exception. The exception may be valid but it is not informative at all and it does not tell you what is the real issue with the data model (could be a field type in the data model that is not supported by SDN, etc... the issue could be anything on the entity, but the error is not helping to figure out what is wrong with the data model.
I can zip my project and share it with you. How can I send you the zip file?

[hamidbm]

I added you to the repo: https://github.com/hamidbm/springboot-rest-datastore
Thanks Gerrit.

[michael-simons]

Hi

• implementation 'org.neo4j:neo4j-ogm-bolt-driver:3.2.5'

This is SDN 5.x and Neo4j-OGM. It is not needed and will cause issues. This is not a driver, this a transport module for OGM.

• The custom config

public class Config  extends AbstractNeo4jConfig implements Trace {

    @Value("${spring.neo4j.uri}")
    private String url;

    @Value("${spring.neo4j.authentication.username}")
    private String username;

    @Value("${spring.neo4j.authentication.password}")
    private String password;

    @Bean
    public Driver driver() {
        String neo4jURL = System.getProperty("NEO4J_URL");
        if ( neo4jURL == null ) neo4jURL = url;
        //info("neo4jURL is: {}", neo4jURL);
        return GraphDatabase.driver(neo4jURL, AuthTokens.basic(username, password));
    }

    @Bean
    public Neo4jTemplate neo4jTemplate(Neo4jMappingContext mappingContext) {
        return new Neo4jTemplate(neo4jClient(driver()), mappingContext, databaseSelectionProvider());
    }
}

is unnecessary when using our starter. You are duplicating what is there 100%.

• Module path: We don't test on the module path as Spring Data Commons is not likely to work without errors on the module path. I'm unsure if your issue is related, but will let you know as soon as I am sure.

[michael-simons]

Same with the application: Why excluding the auto config and than recreating it?

@SpringBootApplication(exclude={Neo4jDataAutoConfiguration.class})
//@EnableNeo4jRepositories("XXX.neo4j.repository")
//@ComponentScan({"XXX.sb"})
public class Application {

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }

    @Bean
    public Neo4jDataProperties neo4jDataProperties() { return new Neo4jDataProperties(); }
}

[michael-simons]

You can omit all the the BigDecimal converters I think…

See: https://docs.spring.io/spring-data/neo4j/docs/6.0.7/reference/html/#conversions

[michael-simons]

I can reproduce the behavior. The underlying issue is that you have

public interface PLI {
}

and

@Node("PLI")
public class PLIEntity implements PLI {
}

Both objects triggering the creation of a persistent entity under the label PLI. Both entities are necessary to make SDN work, but only one should go into our index lookup.
As we do think that your approach is a valid approach, we are gonna fix the behavior.

Your statement about repositories was kind of a red herring: It does happen only when you add EntitlementRepository as the entitlement implementation refers to a Entitlement value and thus triggering the bug.

Anyway, apart from the flaws I mentioned above, I do like your approach and would learn more about you having success in a modularized world.

FWIW we are preparing the CypherDSL to be fully modularized soon.