Hibernate-reactive: Exception removing multiple elements from ordered embeddable collection

Created on 22 Feb 2021  ·  7Comments  ·  Source: hibernate/hibernate-reactive

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

bug

All 7 comments

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

Was this page helpful?
0 / 5 - 0 ratings