running additional tests to check latest Reactive collection persister logic from the @OrderColumn #581 changes. Ran into an issue removing more than 1 element during a flush().
See: OrderedEmbeddableCollectionTest
Exception: [Exception 0] io.vertx.core.impl.NoStackTraceThrowable: The number of parameters to execute should be consistent with the expected number of parameters = [2] but the actual number is [3].
[Exception 1] io.vertx.core.VertxException: Transaction already completed
Appears that the Object[] array of param values is returning an Object[3] instead of Object[2] for the second deleted element in the new abstract persister: https://github.com/hibernate/hibernate-reactive/blob/fe9dfbaa07e4b71fe85e949a45ac23c91c26709b/hibernate-reactive-core/src/main/java/org/hibernate/reactive/persister/collection/impl/ReactiveAbstractCollectionPersister.java#L237
Might be worth getting the test working on Hibernate ORM core, just to be able to step through and see what happens there.
In ORM's deleteRows
the int offset = 1;
never changes.
In Reactive, we're passing the offset into the deleteRowsParamValues( entry, index+1, id, session )
call, which is based on an incremented index
value. Seems we're wrongly combining the concepts of i
, index
, loc
and offset
in ORM.
The i
value appears to provide update and insert methods to know which collection entry is being operated on, so it shouldn't be tied to/used in the delete process.
Yup, it looks like the logic is just wrongly-ported-over.
I think just changing the index+1"
to 1
reflects the ORM logic
Great!
Good catch!
@blafond: I've assigned this to you as it seems you have already a fix
Thanks, @blafond