Well ... I take back some of the stuff I said.
I do think it is a good idea that triggers do not add the generated keys
they create to session.
For example before triggers would add them before the actual statement does.
And to the executor of the statement the generated id's would seem
mysterious if he doesn't
know all the side effects of his insert statement (and in complex data
models he does not).
So here is a small change set that I did that would allow trigger to set
the generated key
WITHOUT BREAKING ANY BACKWARD COMPATIBILITY.
addition to Session.java
private Value triggerGeneratedKey;
public void setTriggerGeneratedKey(Value triggerGeneratedKey) {
this.triggerGeneratedKey = triggerGeneratedKey;
}
public Value getTriggerGeneratedKey() {
return this.triggerGeneratedKey;
}
and then a change in TriggerObject.java starting from line 117 (and
similar changes to fireRow method further down)
Value identity = session.getScopeIdentity();
try {
triggerCallback.fire(c2, null, null);
} catch (Throwable e) {
throw DbException.get(ErrorCode.ERROR_EXECUTING_TRIGGER_3, e,
getName(),
triggerClassName, e.toString());
} finally {
if (session.getTriggerGeneratedKey() != null) { // CHANGED
session.setScopeIdentity(session.getTriggerGeneratedKey()); //
CHANGED
session.setTriggerGeneratedKey(null); // CHANGED
} // CHANGED
else session.setScopeIdentity(identity); // CHANGED
if (type != Trigger.SELECT) {
session.setCommitOrRollbackDisabled(old);
}
}
One could also call the triggerGeneratedKey as globalIdentity,
so it would resemble more the existing terms lastIdentity and scopeIdentity.
What do people think?
- Rami
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.
