Eclipse Community Forums: TMF (Xtext) » Problem with LazyLinkingResource.getEObject()

Help

Home

Home » Modeling » TMF (Xtext) » Problem with LazyLinkingResource.getEObject()

Show: Today's Messages :: Show Polls :: Message Navigator

Problem with LazyLinkingResource.getEObject() [message #895948]

Mon, 16 July 2012 15:39

Joel Bobstein

Messages: 7
Registered: April 2012

Junior Member

Dear XText development team,

We are experiencing an issue with LazyLinkingResource.getEObject().

Since ILinkingService.getLinkedObjects() returns a list, we would expect several matches to be supported by the linker. And instead of an exception, we believe that the linker should report a new diagnostic with something like getViolatedBoundConstraintMessage (exactly the same way it is handled if there is zero match).

Furthermore, in the class Linker, it is exactly how it is programmed. So we don't understand why it would be different for LazyLinkingResource.

Maybe we're missing something. Or maybe it's only a mistake. So we kindly ask for your feedback.

Best Regards,
Joel.

Report message to a moderator

Re: Problem with LazyLinkingResource.getEObject() [message #896429 is a reply to message #895948]

Wed, 18 July 2012 11:39

Sebastian Zarnekow

Messages: 3118
Registered: July 2009

Senior Member

Hi Joel,

the lazy linker is implemented on top of the EMF proxy mechanism. As
soon as a lazy linking proxy should be resolved, the linking is
triggered for that exact instance. This implies that the number of
proxies in a list matches the number of resolved elements thus only one
element may be returned per proxy. There is basically nothing that one
could do about that besides not using the lazy linking but do eager
linking instead.

Best regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com

Am 16.07.12 17:39, schrieb Joel Bobstein:
> Dear XText development team,
>
> We are experiencing an issue with LazyLinkingResource.getEObject().
>
> Since ILinkingService.getLinkedObjects() returns a list, we would expect
> several matches to be supported by the linker. And instead of an
> exception, we believe that the linker should report a new diagnostic
> with something like getViolatedBoundConstraintMessage (exactly the same
> way it is handled if there is zero match).
>
> Furthermore, in the class Linker, it is exactly how it is programmed. So
> we don't understand why it would be different for LazyLinkingResource.
>
> Maybe we're missing something. Or maybe it's only a mistake. So we
> kindly ask for your feedback.
>
> Best Regards,
> Joel.

Report message to a moderator

Re: Problem with LazyLinkingResource.getEObject() [message #898382 is a reply to message #896429]

Thu, 26 July 2012 09:59

Joel Bobstein

Messages: 7
Registered: April 2012

Junior Member

Thank you for your answer.

I'm not sure to understand what you mean. In order to be more specific, this is what I was talking about:

Assuming the variable diagnosticMessageProvider is now declared as an ILinkingDiagnosticMessageProvider.Extended, the method getEObject would be modified as such:

if (linkedObjects.size() > 1) {
	if (isUnresolveableProxyCacheable(triple))
		unresolveableProxies.add(uriFragment);
	if (!isValidationDisabled()) {
		ILinkingDiagnosticMessageProvider.ILinkingDiagnosticContext context = createDiagnosticMessageContext(triple);
		DiagnosticMessage message = diagnosticMessageProvider.getViolatedUniqueConstraintMessage(context);
		if (message != null) {
			List<Diagnostic> list = getDiagnosticList(message);
			Diagnostic diagnostic = createDiagnostic(triple, message);
			if (!list.contains(diagnostic))
				list.add(diagnostic);
		}
	}
	return null;
}

The bottom line being: If the proxy resolution can fail because of zero match, why couldn't it fail because of multiple matches ?

I have kindof tested the code above and it looked like it was doing the job, though I fairly admit I am far from having your expertise in that matter.

Thanks for your patience,
Joel.

Report message to a moderator

Re: Problem with LazyLinkingResource.getEObject() [message #898842 is a reply to message #898382]

Fri, 27 July 2012 22:26

Benjamin Schwertfeger

Messages: 53
Registered: July 2009

Member

Hello Joel,
I think you have another understanding of getEObject, than EMF Resources. The mothod is called once per fragment(proxy) and have to return the one element which replaces the resolved fragment, if possible. Even if the feature themself is a list, the getEObject is called for each (lazy) proxy in the list independent to the other proxies and returns the element which is referenced by this name. In case of lazy links it is a bit more complex to get the name, because two proxies with the same reference name, have different fragments in this step.

If you want to validate, that elements in lists are unique, you have to do it after resolving all elements.

I do not know, why getLinkedObjects returns a list, but guess, that it was initially ment to return alle possible elements, which was not implemented because they have to be loaded and all but the first will be dropped for lazy links.

I hope I caught your point and clarify a bit,

Benjamin

Report message to a moderator