Created follow-up issues for remaining tasks and ideas developed during PR review.

https://github.com/hibernate/hibernate-ogm/pull/501

> About Operation, it is more that this is tuple based and the user thinks entity.

My reasoning is that the tuple-like represention is closer the persistent data in the store, e.g. with respect to data types, column names etc. When e.g. getting a log file with changes that have been applied and need to be revised, this form may be more suitable than the more abstract entity-based representation; E.g. if I need to manually create a statement for compensating a certain change.

, I tried to compile a list of use cases to be supported from your earlier comment and yesterday's IRC discussion, updated the issue description with that. Is there anything missing from your point? I think if we had something which helps users to address 1.1 and 2.1 that'd already be a very good first step.

A few ideas that popped up:

The error handling is called upon failure at flush time.
The error handling needs to be able to say what has worked and what has failed (per flush, maybe per transaction scope)
If transaction scope, verify that WildFly can start and call Synchonized on transactions where no tx resources end up being added. => Gunnar swears on his life that it works already.
The error handling needs to be able to say CONTINUE the other operations or ABORT.
The error handling code should be passed both globally and per operation ( OgmSession.useErrorHandler(...) )
Offer high level operations like "undo" automatically already applied changes, pass a set of tuple operations and apply them.
Gunnar proposes to expose the GridDialect but I think that's a too low level.
Express whether the error is an optimistic error or not (version checking is done in the persister I think.
The error handling code can raise an exception that bubbles up

Use cases:

• upon error, I want to get an exception in the application

  • That means try { .flush() } catch {}

• upon error, user will retry with different values until success

  • offer ability to read the "old value"

  • offer ability to apply a different set of changes to a tuple

• upon error, rollback currently done changes

  • offer a high level undo operations (automatic)

  • this is not transactional so new data might have been read

• upon failure, ignore and keep going

  • requires the CONTINUE

• upon optimistic locking exception, undo all and raise exception

  • undo operations

  • raise exception for bubble up and business handling