@snicoll and I have discussed the following idea:

At the moment, there's auto configuration for Spring Data Neo4j+Object Graph Mapping (In the following SDN+OGM). The auto configuration for SDN+OGM does several things

  • It configures the "OGM Driver". The OGM Driver is an additional abstraction over several ways to address a Neo4j Instance. It can be HTTP, Embedded or the Java Driver.
  • It configures the Spring Data part of SDN+OGM, that is enabling Neo4jRepositories and related infrastructure.

Spring Boot might contain two distinct aspects of configuring Neo4j and Spring Data Neo4j in the future:

  • The Neo4j Java Driver (aka "Bolt driver") should be configured without going through Spring Data Neo4j, so that users can work with the plain driver object like they might do with a JDBC DataSource
  • The configuration would need new properties outside the spring.data namespace
  • The auto configuration for SDN+OGM would need to be improved to act according to this: -- If there's a Driver bean, than use that to configure the OGM part accordingly -- If there's a none, check the old properties whether SDN+OGM can configured as before

This change would require efforts in the current OGM as well.

The benefits of such a change would be

  • More choice for the users (direct Java Driver usage of our product or Spring Data abstraction)
  • An migration path to upgrade to the new Neo4j driver (2.0/4.0, which will be not compatible with OGM).

We have written down about the current building blocks of an SDN+OGM application here.

Our goal is to move users to a server based solution (away from embedded) over the Bolt driver. Embedded is there to stay, but we rather see it as testing support only. That means, we might be touching @DataNeo4jTest eventually as well. It could be improved to use Neo4j's dedicated test harness to create the embedded database in contrast as of today, where it uses OGM.

We started to detangle things by providing an interim starter for the new generation of the Java driver, Neo4jDriverProperties especially shows what we like to configure in the future.

Comment From: snicoll

I suggest we iterate with @michael-simons on the separate starter he has initiated and then revisit the situation once we start work for 2.3 as the new driver should be available.

Comment From: snicoll

@michael-simons can you please provide an update for us? Is the new driver GA? How about the changes that you mentioned in OGM in the original description?

There's no rush on our side, but if we can work on it in the coming months, I'd rather know it asap. Thank you.

Comment From: michael-simons

Hello, the driver is GA since December 2019.

We see our starter (https://github.com/neo4j/neo4j-java-driver-spring-boot-starter) being used, our field team is actually quite happy to be able to configure all properties of the driver OR being able to used it without OGM.

In relation to OGM, the changes we brought in with https://github.com/spring-projects/spring-boot/pull/17662 really help people combining both approaches. I personally know this from being used at a couple of customers.

Comment From: snicoll

Thanks for the feedback. From my perspective, we could proceed with this one if the following is met:

  • The auto-configured driver can be used to configure whatever Spring Data Neo4j needs. In other words, the driver is configured and expose an infrastructure that Spring Data itself uses for its own support
  • The driver in question is the recommended approach going forward (which means that Spring Data Neo4j itself uses it)

I understand that customers like to use Neo4j without "Spring Data" but having both spring.neo4j and spring.data.neo4j and two ways of bootstraping Neo4j is not something that would work here, unless I missed something.

No rush from our end but I'd like to triage this issue.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: spring-projects-issues

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

Comment From: snicoll

This issue is superseded by #22301