Ausführen zusätzlicher Tests, um die neueste Reactive-Sammlungspersistenzlogik aus den @OrderColumn #581- Änderungen zu überprüfen. Hatte ein Problem beim Entfernen von mehr als 1 Element während eines flush().
Siehe: OrderedEmbeddableCollectionTest
Ausnahme: [Exception 0] io.vertx.core.impl.NoStackTraceThrowable: Die Anzahl der auszuführenden Parameter sollte mit der erwarteten Anzahl von Parametern = [2] übereinstimmen, aber die tatsächliche Anzahl ist [3].
[Exception 1] io.vertx.core.VertxException: Transaktion bereits abgeschlossen
Scheint, dass das Array Object[] der Parameterwerte ein Object[3] anstelle von Object[2] für das zweite gelöschte Element im neuen abstrakten Persister zurückgibt: https://github.com/hibernate/hibernate-reactive/blob/ fe9dfbaa07e4b71fe85e949a45ac23c91c26709b/hibernate-reactive-core/src/main/java/org/hibernate/reactive/persister/collection/impl/ReactiveAbstractCollectionPersister.java#L237
Es könnte sich lohnen, den Test mit dem Hibernate ORM-Kern zu arbeiten, nur um durchzugehen und zu sehen, was dort passiert.
In ORMs deleteRows
ändert sich das int offset = 1;
nie.
In Reactive übergeben wir den Offset an den deleteRowsParamValues( entry, index+1, id, session )
Aufruf, der auf einem inkrementierten index
Wert basiert. Scheint, dass wir die Konzepte von i
, index
, loc
und offset
in ORM falsch kombinieren.
Der i
scheint Aktualisierungs- und Einfügemethoden bereitzustellen, um zu wissen, welcher Sammlungseintrag bearbeitet wird, daher sollte er nicht an den Löschvorgang gebunden/verwendet werden.
Yup, es sieht so aus, als ob die Logik nur falsch portiert wurde.
Ich denke, nur die Änderung von index+1"
in 1
spiegelt die ORM-Logik wider
Groß!
Guter Fang!
@blafond : Ich habe dir das zugewiesen, da du anscheinend schon eine Lösung hast
Danke, @blafond