1

ich von SDN 4.2 zu SDN 5 und OGM 3Spring Data Neo4j 5 OGM 3 und Spring-Boot 2.0.0.M4

Alles fast perfekt funktioniert, außer in einem Fall zu migrieren bin versucht.

Gerade jetzt, um die Einheit I Tiefe = 2 statt wie die Tiefe = 1 verwenden, müssen sparen bei SDN 4.2

Es ist schwer, es zu erklären, so dass ich ein Demo-Projekt bei GitHub erstellt habe, die dieses Problem reproduziert - https://github.com/Artgit/spring-boot-2.0.0.M4-sdn5-ogm3-saving-issue

Schritte zum reproduzieren:

Wenn Sie eine eigene Neo4j Instanz verwenden möchten, wenden Sie sich bitte Schritt 1 überspringen und beginnen Sie mit Schritt # 2 zu lesen.

  1. Run mvn docker:start -Dfile.encoding=UTF-8 um Neo4j 3.2.5 in Docker Behälter spin up (Docker muss installiert sein)

  2. Execute Test com.decisionwanted.domain.DecisionCharacteristicIT.testUpdateValue()

Der Test sollte mit der Behauptung fehlschlagen:

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 

Wie Sie von den folgenden sehen können ng Code:

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

assertEquals(user3, rdbmsHorScalingValue.getUpdateUser()); 

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

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

I rdbmsHorScalingValue mit user3 aktualisiert haben und nach Value von id bekommen (valueDao.getById()) Ich erwarte, dass diese Benutzer als rdbmsHorScalingValue.getUpdateUser() aber aus irgendeinem unbekannten Grund, es ist nicht wahr.

Aber wenn wir bei der folgenden Methode ändern: com.decisionwanted.domain.dao.decision.characteristic.value.history.HistoryValueDaoImpl.create(Value) Spar Tiefe 1-2 - alles beginnt fein arbeiten.

Derzeit weiß ich nicht, wo das Problem ist und das einzige, was ich weiß - es funktioniert gut mit Speichern von Tiefe = 1 mit SDN 4.2.

Bitte sagen Sie mir, wo das Problem (warum es nicht mit SDN 5 funktioniert) und wie es zu lösen ist.

Antwort

2

Das Problem ist, mit Ihnen Methode aktualisieren (com.decisionwanted.domain.dao.decision.characteristic.value.ValueDaoImpl#update)

Sie ändern eine Beziehung (UPDATED_BY), die nicht in einer aktuellen Sitzung verfolgt wird (die sich auf eine Transaktion gebunden ist). Es wird Ihre alte UPDATED_BY Beziehung verlassen - Sie enden mit 2 Beziehungen - überprüfen Sie Ihre Grafik in Neo4j direkt. Das Verhalten für diesen Fall ist nicht definiert, OGM erwartet, dass das Graphenmodell das Objektmodell bearbeitet.

Warum es mit Speichern Tiefe 2 funktioniert - das Speichern wird die Value-Instanz und die Beziehung zu Benutzer in die Sitzung hinzufügen (mit Tiefe 1 wird dies nur für die Value-Instanz, nicht die Beziehung) und die anschließende Änderung ist dann detektiert

Sie sollen den Wert Beispiel am Anfang der Update-Methode laden (bis zur Tiefe ändern Sie):

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

Wenn Sie die ValueDao Objekte aus @Transactional Diensten verwenden Sie nicht brauchen, dass , aber die * IT-Tests sollten selbst transaktional sein, um dies widerzuspiegeln.

Verwandte Themen