Home » Modeling » GMF (Graphical Modeling Framework) » RollbackException with emf.transaction: pre-commit validation?
| RollbackException with emf.transaction: pre-commit validation? [message #189520] |
Tue, 27 May 2008 14:35  |
 Andrew J. Montalenti
Messages: 23
Registered: July 2009 |
Junior Member |
|
|
Hi folks,
I recently unified the EditingDomains in my application, which includes a
set of customized emf.editor-based views and editors and a
gmf.diagram-based editor. I did this following some of the advice in the
article on EclipseCorner[1].
I ended up using the DiagramEditingDomainFactory like this for my single
instance:
TransactionalEditingDomain editingDomain =
DiagramEditingDomainFactory.getInstance().createEditingDomai n();
editingDomain.setID("com.my.id");
and I modified my gmf.diagram editor to use a custom IDocumentProvider
that utilized this single instance.
So far, so good. I have EditingDomain sharing working properly, and I am
able to create new model objects in either my custom emf.editor, my custom
view, or my gmf.diagram editor.
However, there's a slight change in behavior with regard to commands that
delete a model object that is referenced by other model objects.
Here is a simplified view of my metamodel:
Entity : EClass {
name : EString
fields : EList<Field>
}
Field : EClass {
<<abstract>>
name : EString
}
Reference : EClass {
^- inherits from Field
entityReference : EReference<Entity>
}
In a model, I might have two Entities like this:
Entity A {
B : Reference<B>
}
Entity B {
}
In other words, Entity A references Entity B. Now, with the
non-Transactional EditingDomain/CommandStack, deleting Entity B would
result in the entityReference EReference in A.B being set to null.
However, with the Transactional EditingDomain/CommandStack, I get an
exception as follows:
THROWN The entityReference value on a reference is missing in 'A' entity.
(org.eclipse.emf.transaction.impl.TransactionImpl#commit)
org.eclipse.emf.transaction.RollbackException: The entityReference value
on a reference is missing in 'A' entity.
at
org.eclipse.emf.transaction.impl.TransactionImpl.commit(Tran sactionImpl.java:349)
at
org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:140)
at
org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
at
org.eclipse.gmf.runtime.diagram.ui.parts.DiagramCommandStack .execute(DiagramCommandStack.java:193)
at
org.eclipse.gmf.runtime.diagram.ui.parts.DiagramCommandStack .execute(DiagramCommandStack.java:168)
at
org.eclipse.gmf.runtime.diagram.ui.actions.DiagramAction.exe cute(DiagramAction.java:141)
at
org.eclipse.gmf.runtime.diagram.ui.actions.DiagramAction.doR un(DiagramAction.java:103)
at
org.eclipse.gmf.runtime.common.ui.action.AbstractActionHandl er.run(AbstractActionHandler.java:359)
The end result of this is that, from the user's standpoint, a 'delete'
command has no effect.
It seems to me that the TransactionalEditingDomain is using some
additional validation that wasn't present in the regular EditingDomain.
I've noticed there are some classes like TransactionValidator in the
TransactionalEditingDomainImpl.
My questions are:
1. How can I hook into this validation logic so that I can take a more
appropriate resolution? I think validating at pre-commit is useful, but
in this case, instead of rolling back the transaction, I'd like to alter
it such that the deletion of a referenced Entity results in the deletion
of any Reference fields that point to that Entity. Do I use
TriggerListeners for this?
2. Is there an easy way to disable this validation altogether (as an easy,
short-term solution)?
3. Where can one find the actual EMF validation constraints that
emf.transaction is using by default (or that DiagramEditingDomain is using
by default)?
Thanks,
Andrew
[1]
http://www.eclipse.org/articles/article.php?file=Article-Int egrating-EMF-GMF-Editors/index.html
|
|
|
| Re: RollbackException with emf.transaction: pre-commit validation? [message #189544 is a reply to message #189520] |
Tue, 27 May 2008 14:48  |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Andrew,
See some replies in-line, below.
HTH,
Christian
On Tue, 2008-05-27 at 14:35 +0000, Andrew J. Montalenti wrote:
> Hi folks,
-----8<-----
> In other words, Entity A references Entity B. Now, with the
> non-Transactional EditingDomain/CommandStack, deleting Entity B would
> result in the entityReference EReference in A.B being set to null.
> However, with the Transactional EditingDomain/CommandStack, I get an
> exception as follows:
>
> THROWN The entityReference value on a reference is missing in 'A' entity.
> (org.eclipse.emf.transaction.impl.TransactionImpl#commit)
> org.eclipse.emf.transaction.RollbackException: The entityReference value
> on a reference is missing in 'A' entity.
> at
> org.eclipse.emf.transaction.impl.TransactionImpl.commit(Tran sactionImpl.java:349)
> at
> org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:140)
> at
> org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
> at
> org.eclipse.gmf.runtime.diagram.ui.parts.DiagramCommandStack .execute(DiagramCommandStack.java:193)
> at
> org.eclipse.gmf.runtime.diagram.ui.parts.DiagramCommandStack .execute(DiagramCommandStack.java:168)
> at
> org.eclipse.gmf.runtime.diagram.ui.actions.DiagramAction.exe cute(DiagramAction.java:141)
> at
> org.eclipse.gmf.runtime.diagram.ui.actions.DiagramAction.doR un(DiagramAction.java:103)
> at
> org.eclipse.gmf.runtime.common.ui.action.AbstractActionHandl er.run(AbstractActionHandler.java:359)
>
>
> The end result of this is that, from the user's standpoint, a 'delete'
> command has no effect.
Right, roll-back automatically undoes the offending changes. The user
will have seen an error dialog of some kind, though, right?
> It seems to me that the TransactionalEditingDomain is using some
> additional validation that wasn't present in the regular EditingDomain.
> I've noticed there are some classes like TransactionValidator in the
> TransactionalEditingDomainImpl.
Yes. I sounds like somebody has implemented a "live" validation
constraint for you using the extensible validation framework
(org.eclipse.emf.validation component). The severity of this constraint
is evidently set to ERROR, which triggers the roll-back.
> My questions are:
>
> 1. How can I hook into this validation logic so that I can take a more
> appropriate resolution? I think validating at pre-commit is useful, but
> in this case, instead of rolling back the transaction, I'd like to alter
> it such that the deletion of a referenced Entity results in the deletion
> of any Reference fields that point to that Entity. Do I use
> TriggerListeners for this?
Exactly. The pre-commit listeners (of whichever form is most convenient
for you) are responsible for appending changes to a transaction that
will pro-actively maintain the integrity of your model.
> 2. Is there an easy way to disable this validation altogether (as an easy,
> short-term solution)?
Well, you could use the "Model Validation" preference page to disable
the constraint in question, if it isn't in a required category.
However, if you didn't implement this constraint in the first place, I
wonder who did? You might check with the owner of your metamodel...
However, triggers fire before validation, so if you ensure that the
constraint won't be violated, then it won't cause any roll-back.
> 3. Where can one find the actual EMF validation constraints that
> emf.transaction is using by default (or that DiagramEditingDomain is using
> by default)?
The transaction simply delegates to the validation service to evaluate
whatever live constraints are provided to it, from any source. So, as I
mentioned above, the question is who provided this constraint on the
org.eclipse.emf.validation.constraintProviders extension point?
>
> Thanks,
>
> Andrew
>
> [1]
> http://www.eclipse.org/articles/article.php?file=Article-Int egrating-EMF-GMF-Editors/index.html
>
>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 07:25:59 GMT 2024
Powered by FUDForum. Page generated in 0.02732 seconds |
] 
Search
Help
Register
Login
Home
