We're in agreement here and yes, when creating the Neo4jConnectionRepository, it must be given *something* to reference the user node for whom the connections are being created. Per the UsersConnectionRepository interface, the createConnectionRepository() method takes a String which is the userId. For Neo4j, that can be a String containing the node ID fo the user node for which the connections will managed. It's a bit odd, as the node ID would really be a numeric value. But the signature of that method is String, so I guess a conversion to/from String will be required to satisfy the method signature.
Originally Posted by maciossek
In the case of JDBC, JdbcUsersConnectionRepository is given a DataSource, from which is creates a JdbcTemplate. Likewise, Neo4jUsersConnectionRepository should be given the most basic thing it can be given to access the database. If you're going to use Neo4jTemplate internally, that's fine (except for the dependency issue I mentioned before), but Neo4jUsersConnectionRepository should be created with something lower-level, such as the graph database bean...pretty much what you said.
The JDBC uses the JdbcTemplate and a set datasource attribute. For Neo4j i do have the Neo4jTemplate, but I think I need to define the graphDatabase bean somewhere in my application, to access it. Right?
I'm not so sure I'd have Neo4jConnectionRepository extend GraphRepository. I'd just have it implement ConnectionRepository and internally use either Neo4jTemplate to do its work or (better, for dependency reasons) work with the database natively.
Therefore I would have the following classes:
Neo4jConnectionRepository extends GraphRepository<Neo4jSocialUser>
In short, even if you're using Spring Data Neo4j internally, I'd keep it out of the external contract of those clasess so that you can rip it out later without changing the contract. Ideally, SDN wouldn't even be a dependency...but I understand your desire for an iterative approach using SDN to start. Just try to avoid getting too tied to SDN in the external contract so that it won't be hard to remove it in a later iteration.
Spring Social Project Lead