exécuter des tests supplémentaires pour vérifier la dernière logique de persistance de la collection réactive à partir des modifications @OrderColumn #581 . A rencontré un problème lors de la suppression de plus d'un élément lors d'un flush().
Voir : OrderedEmbeddableCollectionTest
Exception : [Exception 0] io.vertx.core.impl.NoStackTraceThrowable : Le nombre de paramètres à exécuter doit être cohérent avec le nombre attendu de paramètres = [2] mais le nombre réel est [3].
[Exception 1] io.vertx.core.VertxException : Transaction déjà terminée
Il semble que le tableau Object[] de valeurs param renvoie un Object[3] au lieu de Object[2] pour le deuxième élément supprimé dans le nouveau persister abstrait : https://github.com/hibernate/hibernate-reactive/blob/ fe9dfbaa07e4b71fe85e949a45ac23c91c26709b/hibernate-reactive-core/src/main/java/org/hibernate/reactive/persister/collection/impl/ReactiveAbstractCollectionPersister.java#L237
Cela pourrait valoir la peine de faire fonctionner le test sur le noyau d'Hibernate ORM, juste pour pouvoir passer en revue et voir ce qui se passe là-bas.
Dans les deleteRows
ORM, le int offset = 1;
ne change jamais.
Dans Reactive, nous passons le décalage dans l'appel deleteRowsParamValues( entry, index+1, id, session )
, qui est basé sur une index
incrémentée de i
, index
, loc
et offset
dans ORM.
La i
semble fournir des méthodes de mise à jour et d'insertion pour savoir sur quelle entrée de collection est exploitée, elle ne doit donc pas être liée/utilisée dans le processus de suppression.
Oui, il semble que la logique soit simplement mal transférée.
Je pense que changer le index+1"
en 1
reflète la logique ORM
Super!
Bonne prise!
@blafond : je vous ai attribué cela car il semble que vous ayez déjà un correctif
Merci @blafond