EDIT

Hallo Andreas

die Umstellung auf Single-Source-Referenzen bei TaxonName verträgt sich mit dem TaxonGraphBeforeTransactionCompleteProcess (noch) nicht. Und daher schlägt der Test TaxonGraphHibernateListenerTest.testChangeNomRef() auch Alarm. Folgendes passiert hier:

        Reference refX = ReferenceFactory.newBook();
  refX.setTitleCache("Ref-X", true);;
  TaxonName n_trachelomonas_a = nameDao.load(uuid_n_trachelomonas_a);
  n_trachelomonas_a.setNomenclaturalReference(refX);
  nameDao.saveOrUpdate(n_trachelomonas_a); ----> jetzt wird gespeichert und in folgender Reihenfolge kaskadiert:

1. die Referenz
2. der TaxonName
3. die DescriptionSource

Der TaxonGraphBeforeTransactionCompleteProcess wird über das Speichern des TaxonNamen getriggert. Die Vor- und Nach-Statedata von nomencalturalSource.ciatation sind aber an diesem Punkt immer schon die neue Referenz, denn Hibernate hat hier keinen Zugriff auf den alten State der citation "Ref-X" und man kann nur vergleichen was im Objekt steckt das in der Session liegt. Das der alte State der Referenz sich durch n_trachelomonas_a.setNomenclaturalReference(refX); geändert hat wird daher nicht erkannt.

Soweit zum Stand der Dinge. Ich überlege jetzt wie man das lösen kann. Eine Frage dazu:

• Ist die Reihenfolge der Kaskadierung irgendwo definiert und deterministisch und verlässlich, oder kann sich das auch mal durch ein Hibernate Update verändern?

Viele Grüße
Andreas

Hallo,

die sicherste und einfachste Lösung a) wäre eine neue DescriptionSource zu erzeugen wenn sich die citation ändert. Dadurch wäre gewährleistet, dass das vom TaxonName aus auch während des SessionFlush auch detektiert werden kann.

Alle anderen Möglichkeiten halte ich für problematischer:

b) neue Klasse NomenclaturalSource als Unterklasse von DescriptionSource. NomenclaturalSource hat dann eine bidirektionale beziehung zum TaxonNamen. Damit könnte ich den TaxonGraphHibernateListener so erweitern, dass er auch auf das Persisieren von NomenclaturalSource anspringt und gegebenenfalls den Taxongraphen aktualisiert.

c) Ich gehe hier mal davon aus dass die Actions in der ActionQueue eine determinierte Reihenfolge haben. Wenn nicht ließen diese ich noch mit einem Sorter in der Reihenfolge festnageln, aber nach dem Kommentar in ActionQueue gehe ich davon aus dass wir und in diesem Fall auf die Reihenfolge verlassen können ("Object insertions, updates, and deletions have list semantics because they must happen in the right order so as to respect referential integrity"). Da wie unten geschrieben DescriptionSource nach TaxonName könnte man aus der DB mit einer Query die Referenz-ID auslesen und so "oldState" von nomenclaturalSource.citation einfach nachschauen.

c) ist mit der Unsicherheit behaftet dass sich die Reihenfolge der Actions in der Queue ändern könnte oder in gewissen Situationen anders ist als wir es erwarten. Leider hat man keinen Zugriff auf die insertions und updates in der ActionQueue sonst gäbe es noch eine Möglichkeit d):

d) alle ExecutableLists also insertions und updates auf DescriptionSource entities scannen und die nomencalturalSource des TaxonNamen finden. Wenn diese in der Queue steckt kann man in der jeweiligen EntityAction den oldState von citation auslesen und mit dem aktuellen Objekt in nomencalturalSource.ciatation vergleichen. Mit Reflection kann man an diese ExecutableLists schon rankommen aber das ist schon hacky und kann je nach security policy problematisch sein.

Viele Grüße
Andreas

Solved, and can be closed.

@Andreas Müller: can you think of a situation which is not yet covered by the new implemented test methods ?