Mapping incomplete for multi-value features

[StephanErb]

I will make an example: Consider a multi-value feature of type string in which we store first, second and third.

We can parse/pretty print this and get three corresponding tokens. All three tokens contain the same sequence element but no information to which particular string they belong. We basically don't know that the first token corresponds to first, the second to second and so on.

This issue is complicated by the fact that the feature may be unordered. After saving and reloading our resource, the feature may contain second, third and first. We therefore can't rely on any ordering information when trying to perform the matching of tokens and model elements.

I came across this problem when I short pretty printed a complete textblocks model. The short pretty printer uses the following code and therefore fails:

private String handlePropertyElement(Property se, LexedToken token) {
    ...
    Object propertyValue = null;
    try {
        propertyValue = investigator.get(contextObject, se.getPropertyReference().getStrucfeature().getName());
        if (propertyValue instanceof Collection<?> && ((Collection<?>) propertyValue).size() > 0) {
            propertyValue = ((Collection<?>) propertyValue).iterator().next();
        }
    } catch (ModelAdapterException e) {
        // element does not have such a property
    }

So, do we need to extend our usage of the referencedElements relation?

[StephanErb]

Thomas, what do you think?

\CC @tgold

[tgold]

Hm good question... I assume that this is only relevant for primitive typed attributes with multiplicity > 1, right?

I think there is no possibility to distinguish between the following two cases for an unordered, primitive, multivalued attribute:

1. " first, second, third" is writtin in the textual representation, then serialzed and closed. Afterwards the model is deserialized and loaded again resulting in the "second, third, first" order as you mentioned.

2. " first, second, third" is writtin in the textual representation, then serialzed and closed. Afterwards the model is deserialized and loaded again resulting in the same order "fist, second, third" in a different view the attributes are now changed by their value: "first" -> "second", "second" -> "third" and "third" -> "first". The model is serialized, view closed and deserialized again resulting in the same order "second, third, first".

We cannot distinguish if the actual values have changed or if the change is only due to the unorderdness and random order due to serialization/deserialization.

I would propose the following: If we encounter a primitive valued, unorder attribute. The pretty printer shall (if possible) check whether there was an order defined in the previous textblocks model and all values are still present. Then the ordering from that previous textblocks model shall be preserved. Otherwise the order given by deserialization shall be used to create the textblocks model.

What do you think about this solution?

[StephanErb]

Yes, that should work from the perspective of the pretty printer.

At the moment, I am more concerned with the short-pretty-printer and the way it is called. Its method is defined as String resynchronizeToEditableState(AbstractToken token) and used in many different places. The problem is that we do lack the total context information and are just given a single token.

But I just got an idea for a somewhat stupid/slow solution that does not require us to change the public interface.

[StephanErb]

This fix should work in most cases. It will however fail when the multi-valued metamodel property is set to be unique, but the user is typing the same string more than once. The simple counting logic will then be confused and crash or return a random value.