Alternative approach for HREACT-34

[Sanne]

Slightly revised alternative to #1683

This is a more minimalistic patch, so it helps to highlight the difference; but I'm less fond of this appraoch as it doesn't have any safeguard to avoid repeating a similar mistake in the future (besides integration tests, I'm trying to also have some assertions or similar internal state self-checks)

[DavideD]

What if we delegate the management of the stage to a dedicated class? Something like this: DavideD@081e6cb

We could also avoid the case where stage can be null with a small change in Hibernate ORM: we could add a method doNothing(), or add a method doUpdate(updateType). This way we know in which case we are in reactive.

[Sanne]

@DavideD ok, yes I like the intent of adding some validations - that's close to what I had in mind.
But I'm wondering if we could improve it futher?

• rather than having an extra class StageSupplier (defined and allocated) and an extra wrapper (AtomicReference) to be allocated, use some "simple fields".
• have any efficiency penalties guarded as an assertion?

Wondering also - but maybe this is for another day - if we should implement a custom CompletableFuture which could internalize such checks (and perhaps other checks too, in the future).

[DavideD]

Wondering also - but maybe this is for another day - if we should implement a custom CompletableFuture which could internalize such checks (and perhaps other checks too, in the future).

That's a cool idea, but I agreee, it's for a separate issue

[DavideD]

rather than having an extra class StageSupplier (defined and allocated) and an extra wrapper (AtomicReference) to be allocated, use some "simple fields".

I guess in the end it's not much different that the other PR.... ok, I'm fine merging the other solution after some clean up.
I think we can close this one.

[DavideD]

We've merged the other solution. I'm closing this one.