Control automapping from root level by allowing @Mapping

[sjaakd]

Besides the prototype methods in a shared config, it should be possible to control the auto-mapping from the root object graph method. With control I mean:

1. ignore a target
2. direct MapStruct to select the right target if names between source and target do not match.

Currently we have nested source / nested target mappings @Mapping to allow arbitrary selection if properties in a source object graph and map those to arbitrary properties in the target object graph. This is done by @Mapping( target = "tbean.propX.propX1", source = "sbean.propY.propY1.propY11" ). For all clarity: it does not seem to make sense add an ignore option like for instance: @Mapping( target = "tbean.propX.propX2", ignore = true ), since this property would not have been mapped anyway.

Auto-mapping changes things. MapStruct starts to generate mappings automatically based on names. It is essentially different from the nested source / nested target concept however. It requires the source object graph to mirror its target object graph (they are more or less supposed to be symmetrical). MapStruct generates a mapping between each of the properties.

So suppose source:

sbean.propX.propX1 -> tbean.propX.propX1
sbean.propX.propX2 -> tbean.propX.propX2
sbean.propY.propY1 -> tbean.propB.probB1

Now suddenly it would make sense to define mappings.
@Mapping( target = "tbean.propX.propX2", ignore = true)
@Mapping( target = "tbean.propB.probB1", source="sbean.propY.propY1")

1. Do we want to implement this? In principle we have the prototype methods to do this, but that mechanism might be cumbersome to use
2. Do we want to use the same notation? Also for ignores?. Any problems foreseen here?
3. Is there a mixed scenario conceivable in which the nested source / nested target concept is mixed with auto-mappings? If so, if we reuse the current mechanism we possibly need to use update mappings.

[agudian]

I commented that at another point already, but for the sake of the discussion here:

I would expect that the following two declarations would create the same results (just with a different visibility of fishToFishDto:

    @Mapping(target = "fish.kind", source = "fish.type")
    FishTankDto toFishTankDto(FishTank source);

is should basically just be a short-cut to this:

    FishTankDto toFishTankDto(FishTank source);

    @Mapping(target = "kind", source = "type")
    FishDto fishToFishDto(Fish fish);

And to get the blood pressure up, I'd even say that supporting this behaviour is more important than supporting the selected nested-source to nested-target mapping 😱.

[filiphr]

1. Do we want to implement this? In principle we have the prototype methods to do this, but that mechanism might be cumbersome to use
2. Do we want to use the same notation? Also for ignores?. Any problems foreseen here?

I think that with #1046 we actually have this implemented. The FishTankMapper depicts exactly that. If we add an ignore then it would have been ignored.

3. Is there a mixed scenario conceivable in which the nested source / nested target concept is mixed with auto-mappings? If so, if we reuse the current mechanism we possibly need to use update mappings.

Basically we are always going to create automappings for elements that have no mapping. I don't see how this can be a problem.

What we currently have open is using Configurations for the automapping it is one of the open points in #1001

[filiphr]

@agudian I agree with your comment

And to get the blood pressure up, I'd even say that supporting this behaviour is more important than supporting the selected nested-source to nested-target mapping

I have been trying to "fix" that and I am a bit stuck. You can see my reasoning in #1060

[filiphr]

#1072 has been merged