printemps données Neo4j 5 3 et Spring OGM Boot 2.0.0.M4

Question

Je suis en train de migrer de SDN 4.2 à SDN 5 et OGM 3

Tout fonctionne presque parfaitement, sauf un cas.

En ce moment, afin de sauver l'entité que je dois utiliser la profondeur = 2 au lieu de profondeur = 1 comme à NRS 4.2

Il est difficile d'expliquer, donc je l'ai créé un projet de démonstration à GitHub qui reproduit cette question - https://github.com/Artgit/spring-boot-2.0.0.M4-sdn5-ogm3-saving-issue

Procédure pour reproduire:

Si vous voulez utiliser votre propre instance Neo4j s'il vous plaît sauter l'étape 1 et commencer la lecture de l'étape 2.

1. Run mvn docker:start -Dfile.encoding=UTF-8 pour filer jusqu'à Neo4j 3.2.5 dans le récipient Docker (Docker doit être installé)

2. exécuter le test com.decisionwanted.domain.DecisionCharacteristicIT.testUpdateValue()

Le test devrait échouer avec l'affirmation:

java.lang.AssertionError: expected:<BaseEntity [id=3, class=class com.decisionwanted.domain.model.user.User, createDate=Wed Oct 04 21:54:17 EEST 2017, updateDate=Wed Oct 04 21:54:17 EEST 2017]> but was:<BaseEntity [id=2, class=class com.decisionwanted.domain.model.user.User, createDate=Wed 

Comme vous pouvez le voir à la suite Code ng:

rdbmsHorScalingValue = valueDao.update(rdbmsHorScalingValue, newStringValue2, newStringDescription2, user3, 
       null); 

assertEquals(user3, rdbmsHorScalingValue.getUpdateUser()); 

rdbmsHorScalingValue = valueDao.getById(rdbmsHorScalingValue.getId()); 

assertEquals(user3, rdbmsHorScalingValue.getUpdateUser()); // Error here !!!! 

J'ai mis à jour rdbmsHorScalingValue avec user3 et après avoir obtenu Value par id (valueDao.getById()) j'attends cet utilisateur comme rdbmsHorScalingValue.getUpdateUser() mais pour une raison inconnue, il est pas vrai.

Mais si nous changeons à la méthode suivante: com.decisionwanted.domain.dao.decision.characteristic.value.history.HistoryValueDaoImpl.create(Value) économiser la profondeur de 1 à 2 - tout commence à fonctionner correctement.

À l'heure actuelle, je ne sais pas où est le problème et la seule chose que je sais - il fonctionne très bien avec économie de profondeur = 1 avec SDN 4.2.

Se il vous plaît me dire où est le problème (pourquoi il ne fonctionne pas avec SDN 5) et comment faire pour le résoudre.

Answer 1

Le problème est avec vous la méthode mise à jour (com.decisionwanted.domain.dao.decision.characteristic.value.ValueDaoImpl#update)

Vous changez une relation (UPDATED_BY), qui ne sont pas suivis dans une session en cours (qui est lié à une transaction). Il quittera votre ancienne relation UPDATED_BY - vous vous retrouverez avec 2 relations - vérifiez directement votre graphique dans Neo4j. Le comportement pour un tel cas est indéfini, OGM s'attend à ce que le modèle de graphe traite le modèle d'objet.Pourquoi cela fonctionne avec la profondeur d'enregistrement 2 - la sauvegarde ajoutera l'instance Value et la relation à l'utilisateur dans la session (avec la profondeur 1, elle le fera uniquement pour l'instance Value, pas la relation) et la modification suivante est alors détecté

vous devez charger l'instance de valeur au début de la méthode de mise à jour (jusqu'à la profondeur modification):

value = valueRepository.getById(value.getId()); 

Si vous utilisez les objets ValueDao de @Transactional services que vous n'avez pas besoin que , mais les tests informatiques * devraient eux-mêmes être transactionnels pour refléter cela.