Community
Participate
Working Groups
When calculating a logical model for a resource the EMFModelProvider caches the calculated model not only for the resource itself but for all resources which are affected by the logical model. This is done under the assumption that the logical model is the same for each resource. But this is mostly not the case. Resolution Setting: Workspace - Here the assumption holds. The calculated logical model is the same for each resource. Resolution Setting: Outgoing - Here the assumption does not hold. The calculated logical model is actually different for each resource. Consider modelA -> modelB -> modelC. The logical models are: * {modelA, modelB, modelC} for modelA * {modelB, modelC} for modelB * {modelC} for modelC Because of the caching mechanism the EMFModelProvider returns different logical models depending on the order they are calculated. For example, it may return {modelA, modelB, modelC} for all resources if the logical model of modelA was asked for first. It may also return all three different types of logical models if modelC is asked for first. Resolution Setting: Container - Here the assumption does not hold. The calculated logical model may be different for some resources. Consider modelA -> dir/modelB, dir/modelB -> dir/modelC. The logical models are: * {modelA, modelB, modelC} for modelA * {modelB, modelC} for modelB and modelC Depending on the calculated order, the EMFModelProvider may return both of the calculated models for modelB and modelC (or one each). Resolution Setting: Project - Here the assumption does not hold. I did not try it, but since nested projects are actually supported now, you should be able to construct the same scenario as for the container setting.
> Resolution Setting: Workspace > - Here the assumption holds. The calculated logical model is the same for > each resource. No issues there. > Resolution Setting: Outgoing > - Here the assumption does not hold. The calculated logical model is > actually different for each resource. Consider modelA -> modelB -> modelC. > The logical models are: > * {modelA, modelB, modelC} for modelA > * {modelB, modelC} for modelB > * {modelC} for modelC > Because of the caching mechanism the EMFModelProvider returns different > logical models depending on the order they are calculated. For example, it > may return {modelA, modelB, modelC} for all resources if the logical model > of modelA was asked for first. It may also return all three different types > of logical models if modelC is asked for first. The assumption does not hold, but it returns the best result possible IMO. This cache is only available for the computation launched during one given operation (subsequent operations will use a different context and thus can't get a hit in cache). Given that it's only available for one given operation, returning the _initial_ result is actually the best outcome. If the user has asked to compare "B" with another version, the logical model to consider is [B, C], even if somehow the computation will come later to ask what the logical model of "C" is (since that's the same operation, we want it to continue operating on the two models). That's at least my understanding, and if it's wrong, I'd like an unit test or reproduction steps to show why. The same logic applies for your next examples.
Thanks for your detailed explanation. I see your point that for a given context only "better" logical models are returned, so it seems okay for the EMFModelProvider to "break" the assumption as it is defined for each single resource without context. If this potential cause for indeterminism does not matter -- since all relevant users of this class can cope with it -- that is fine for me. I stumbled upon this issue when investigating bug #466607 (redundant merges). During debugging the issue suddenly vanished since the EMFModelProvider returned other ResourceMappings (order of resources is not defined).
