EDIT

Discussion on "include()" handling in Update/DeleteResult:

AM:

Ich habe mir den Code jetzt noch nicht genau angeschaut, aber das mergen der Results soll erstmal dazu führen, dass man alle Ergebnisse (aktualisierte Objekte, gelöschte Objekte) der verschiedenen Operationen an einer Stelle hat, wenn ein Objekt nicht gelöscht werden konnte, dann kann das natürlich zu Verwirrung führen.

Genau das meinte ich. Updated objects, inserted objects und deleted objects sollten natürlich gemerged werden. Bei dem Rest sollten wir aber vorsichtiger vorgehen. Im vorliegenden Fall war es so, dass das Ergebnis von „isDeletable()“ (also nicht mal vom Löschen selber, da dieses ja gar nicht stattfand und nicht stattfinden sollte) des Taxons als Basis genommen wurde und somit alle Exceptions und related objects ungeprüft übernommen wurden ins Endresult. Das scheint mir nur bedingt sinnig.

KL:

Ich habe mir den Code jetzt noch nicht genau angeschaut, aber das mergen der Results soll erstmal dazu führen, dass man alle Ergebnisse (aktualisierte Objekte, gelöschte Objekte) der verschiedenen Operationen an einer Stelle hat, wenn ein Objekt nicht gelöscht werden konnte, dann kann das natürlich zu Verwirrung führen. Ich schaue mir deinen Commit an und dann können wir nochmal überlegen, ob man das anders handeln sollte. Vielleicht würde an der Stelle ja auch einfach eine erweiterte Message reichen.

AM:

ich habe den failing Test jetzt gefixt. Könntest du dir den zugehörigen Commit ca6a3e3608b0e67fa273 nochmal anschauen? Ich glaube da was falsch in der Result-Behandlung in der Methode, was vorher nicht auffiel, weil die include-Methode etwas anders war.

Das scheint mir aber ein grundsätzliches Problem zu sein. Wenn du das result eines optionalen Löschversuchs eines abhängigen Objekts (hier Löschen von Taxon, wenn TaxonNode gelöscht werden soll) zusammen merged in das eigentliche Result ist es schwierig auseinander zu halten, was wozu gehört. Wozu dient dieses mergen? Soweit ich sehe nur dazu, um dann sagen zu können, dass das Taxon nicht gelöscht werden könnte, was kein Fehler ist, sondern nur eine Info. Die Exceptions und UpdatedObjects hier zusammenzuführen scheint mir nicht ganz richtig. Besser sollte die Information separat gespeichert werden, welches optionale Objekt nicht gelöscht werden konnte, zusammen mit dem zugehörigen DeleteResult als Paar [undeletedObject, result] oder so.
Oder übersehe ich da was?

Discussion on how to use UpdateResult in aggregations:

KL:

leider gibt es noch keine Dokumentation, wann was verwendet wird. Aktuell wird meistens updatedObjects verwendet, aber im Falle der Aggregation fände ich UUIDs besser, weil ich ja dann DTOs in der Matrix brauche, die kann ich dann über die UUIDs holen.

Aktuell werden neu erzeugte Objekte entweder über das cdmEntity oder updatedObjects übergeben, also wenn das UpdateResult beim Erzeugen eines Objekts verwendet wird, dann wird cdmEntity verwendet.
Vielleicht muss man da aber auch nochmal etwas strukturierter vorgehen.

Ich brauche nur die UUIDs der Descriptions der Aggregationen, alles andere kommt dann ja mit den DescriptionDTOs mit bzw die Klone werden in der Matrix nicht angezeigt.

Wenn bei der Aggregation ganze Descriptions gelöscht werden, dann müsste das auch im result stehen, alles andere würde über das Austauschen/Zufügen der Descriptions passieren.

AM:

ich bin gerade an https://dev.e-taxonomy.eu/redmine/issues/9843 und habe bereits das UpdateResult in ein DeleteResult umgestellt, damit ggf. gelöschte Descriptions erfasst werden können. Korrekt?

Dennoch habe ich noch Fragen zur Verwendung von UpdateResult.

1. Gibt es irgendwo eine Dokumentation, wann updatedCdmIds und wann updatedObjects verwendet werden müssen/sollen?
2. Wie sollen Objekte, die neu erzeugt werden eingegeben werden? Sind das auch updatedXXX?

Wird das irgendwie systematisch verwendet? Wenn ja, sollten wir das in die Javadoc mit aufnehmen.

Zum konkreten Fall zudem: du brauchst lediglich die Description UUIDs von den aggregierten Taxondescriptions (und ggf. gelöschten Aggregationen), korrekt. Ich könnte natürlich auch viel detaillierter z.B. neue, geupdatete oder gelöschte QuantitativeData und CategoricalData sowie Sources inkl. geclonten Descriptions mit aufnehmen. Macht das Sinn bzw. brauchst du die irgendwie?