Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nested target properties uses same method for different mappings #1148

Closed
filiphr opened this issue Mar 22, 2017 · 5 comments
Closed

Nested target properties uses same method for different mappings #1148

filiphr opened this issue Mar 22, 2017 · 5 comments
Assignees
Labels
Milestone

Comments

@filiphr
Copy link
Member

filiphr commented Mar 22, 2017

It comes from this Stack Overflow question.

In a nutshell:

@Mapper
public interface MyMapper {

@Mappings({
        @Mapping(source = "senderId", target = "sender.id"),
        @Mapping(source = "recipientId", target = "recipient.id")
    })
    Entity toEntity(Dto dto);
}

Generates:

public class MyMapperImpl implements MyMapper {

    @Override
    public Entity toEntity(Dto dto) {
        if ( dto == null ) {
            return null;
        }

        Entity entity = new Entity();

        entity.setRecipient( dtoToClient( dto ) );
        entity.setSender( dtoToClient( dto ) );

        return entity;
    }

    protected Client dtoToClient(Dto dto) {
        if ( dto == null ) {
            return null;
        }

        Client client = new Client();

        client.setId( dto.getRecipientId() );

        return client;
    }
}

It should generate 2 dtoToClient methods instead of one. We most probably need to extend the the PropertyMapping to have the nested name as well and use that somehow in the equals

@filiphr filiphr changed the title Nested target property uses same method for different mappings Nested target properties uses same method for different mappings Mar 22, 2017
@filiphr filiphr added the bug label Mar 22, 2017
@filiphr filiphr added this to the 1.2.0.CR1 milestone Mar 22, 2017
@filiphr
Copy link
Member Author

filiphr commented Mar 23, 2017

Until the bug is resolved one can use a mapper like:

@Mapper
public interface MyMapper {

    @Mappings({
        @Mapping(source = "dto", target = "sender", qualifiedByName = "sender"),
        @Mapping(source = "dto", target = "recipient", qualifiedByName = "recipient")
    })
    Entity toEntity(Dto dto);


    @Named("sender")
    @Mapping(source = "senderId", target = "id")
    Client toClient(Dto dto);

    @Named("recipient")
    @Mapping(source = "recipientId", target = "id")
    Client toClientRecipient(Dto dto);
}

@sjaakd, @agudian, @gunnarmorling this looks a bit complex to fix (if we want to reuse methods). We do this recursively ans when we reach the second level we have lost everything until there... Do you have some suggestion.

@sjaakd
Copy link
Contributor

sjaakd commented Mar 25, 2017

We do this recursively ans when we reach the second level we have lost everything until there... Do you have some suggestion.

I thought a mapping method is characterized by its signature (excluding the name) and its mappings. Mapping getRecipient is something different than a mapping getSender.. Right? So does the equals work correctly?

@filiphr
Copy link
Member Author

filiphr commented Mar 25, 2017

If by mappings you mean the PropertyMapping(s) then yes it is characterized by them. However, currently a PropertyMapping is the same if they have the same name and type. We didn't had access to the source property entries for it.

I think that I found a way for this, we just have to pass the SourceReference.getPropertyEntries() to the PropertyMapping and use them to see if they are same. I am running the suite locally and if everything is OK, I'll make a PR.

@filiphr
Copy link
Member Author

filiphr commented Mar 25, 2017

@sjaakd thanks for the comment, it inspired me for the solution :)

@filiphr
Copy link
Member Author

filiphr commented Apr 20, 2017

A workaround for going live with 1.2.0.CR1 would be to raise a compile error if something like this can occur, so not to generate a wrong code

filiphr added a commit to filiphr/mapstruct that referenced this issue Apr 24, 2017
…pping are considered in the equals of a PropertyMapping
filiphr added a commit to filiphr/mapstruct that referenced this issue Apr 24, 2017
…ptions are restricted to the defined mappings
filiphr added a commit to filiphr/mapstruct that referenced this issue May 21, 2017
…ptions are restricted to the defined mappings
filiphr added a commit to filiphr/mapstruct that referenced this issue May 23, 2017
…ptions are restricted to the defined mappings
filiphr added a commit that referenced this issue May 24, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants