[Use Case]: SQL MERGE and lifecycle events

[gavinking]

As a ...

• Application user/user of the configuration itself
• API user (application developer)
• SPI user (container or runtime developer)
• Specification implementer

I need to be able to ...

have well-defined behavior of lifecycle events when @Save is implemented as an upsert.

Which enables me to ...

not be surprised.

Additional information

Currently, the documentation for @Save says:

 * <p>The operation performed by the annotated method depends on whether the database already holds an entity with the
 * unique identifier of an entity passed as an argument:
 * </p>
 * <ul>
 * <li>If there is such an entity already held in the database, the annotated method must behave as if it were annotated
 *     {@link Update @Update}.
 * <li>Otherwise, if there is no such entity in the database, the annotated method must behave as if it were annotated
 *     {@link Insert @Insert}.
 * </ul>

Thus, implicitly, I guess one could infer that a PreUpdateEvent event should occur in the first case, and a PreInsertEvent in the second case.

But in many cases, the most efficient implementation of @Save is using an upsert (e.g. a SQL MERGE statement), and in that case we would not know whether we're observing an update or insert until after the operation is executed.

A possible solution is to introduce a new event type PreUpsertEvent (or PreMergeEvent).

Thoughts?

[njr-11]

Given the current documentation:

PreInsertEvent states that is is specifically for @Insert: "An event that occurs when an {@link jakarta.data.repository.Insert} lifecycle method is called..."

And similar for PreUpdateEvent: "An event that occurs when an {@link jakarta.data.repository.Update} lifecycle method is called..."

My interpretation of what is currently defined is that no events would be sent for @Save.

It agree it would be a good idea to clarify after deciding on what behavior we want for it. A new event type for Save seems appropriate.