Reputation: 753
According to the migration of SDN (Spring-data-neo4j) v3 to SDN4, Indexes are not present anymore, so this is not foreseen to work anymore.
@NodeEntity
public class User extends Unversioned{
@Indexed(unique=true,failOnDuplicate = true) // <-- THIS
private String login;
...
}
According to here or there, no-one seems surprised. Isn't that the "point" to have constraints defined on the model itself ?
The mission defined on the main page of Sring-data:
Spring Data’s mission is to provide a familiar and consistent, Spring-based programming model for data access while still retaining the special traits of the underlying data store.
Even when comparing to the latest Spring-data-JPA official example, constraints are still defined on the model:
@Entity
public class Customer extends AbstractEntity {
private String firstname, lastname;
@Column(unique = true)
private EmailAddress emailAddress;
Allowing constraints to be defined on the very java-based-model seemed to me to be the less error-prone system. How are we supposed to build a model consistent if the model & constraints are decoupled ? What am I missing ?
Upvotes: 0
Views: 520
Reputation: 15086
I will try to give you an answer "from the trenches". I used SDN 3.x quite a lot, now I use 4.x, I also use spring data mongo, which has @Indexed
annotation.
I agree it is very convenient when you just want to create an index on a property.
But there are several problems in the long run. When the application is deployed and maintained I had to resort to managing indexes in code, not declaratively.
These include
@Indexed
on a property in a base class - what index(es) are created? Just for the base class label? (or collection in mongo), all children...?In the end you trade one line with @Indexed
annotation for another
@Autowired
private Neo4jOperations operations;
@PostConstruct
public void createIndexesAndConstraints() {
...
operations.query("CREATE INDEX ON :Person(email)", EMPTY_MAP);
...
}
Upvotes: 2
Reputation: 19373
As of SDN 4, index management is considered to be out of scope for the mapping framework, and it is recommended that they be managed outside of Spring.
Upvotes: 1