We could store the generated values in a wrapper object with the ability to retrieve values based on name / model part. That would be nice even for enabling nested sub-generators inside composite identifiers to be supported when using on-execution value generation (would be a nice follow-up for ).

Just as a note, the API signature for insert is not the only bottleneck, generating the insert-returning statement through insert delegates also assumes single basic valued identifiers so this would need a pretty big change in generator logic.

How about a new API method for insert that returns a wrapper object, providing access to all sorts of generated values? Reading the row id is a nice improvement and ties in with the recent work on fixing a bug due to missing row id values, but ultimately, I think it’s worth trying to read all insert/update generated data through such a mechanism to avoid round-trips.

I looked into this and it should be possible to implement; the main obstacle I currently see is that we assume the insert operation to return a single Object value, representing the identifier of the entity instance we just inserted. This is assumed through different API levels, so I don’t think changing the return type expected from the insert operation would be doable.

Any proposals / ideas where the row-id value could be stored to allow “insert … returning” of both identity columns and row-ids?