Skip to content

Ignore mappings by default #1392

Closed
Closed

Description

@mowcixo

As Augusto Breno described at Google Groups (https://groups.google.com/forum/?fromgroups#!searchin/mapstruct-users/ignore%7Csort:date/mapstruct-users/BDaK45b3rAg/V1amaHESBwAJ) it would be great to have the possibility of ignore mappings by default.

And yes, as @agudian said at the same topic, it can result a little odd based on the main purpose of MapStruct, but it can be very useful in cases like I'll try to describe:

In some cases you have a class that has copied values from another for historical purposes, for example, an invoice and a customer. And at the same time, both classes have some fields that have the same name.

class Invoice {

    private Long id;

    private String code;

    // Customer historical fields

    private String customerNoun;

    private String customerSurname;

    // getters and setters ....

}

class Customer {

   private Long id;

   private String code;

   private String noun;

   private String surname;

    // getters and setters ....

}

Then, you may have following mapping definition to copy values from Customer to Invoice:

// ...
    @Mappings({
            @Mapping(source = "noun", target = "customerNoun"),
            @Mapping(source = "surname", target = "customerSurname"),
            @Mapping(target = "id", ignore = true),
            @Mapping(target = "code", ignore = true)
    })
    public abstract void fillInvoice(Customer customer, @MappingTarget Invoice invoice);
// ...

If you have just two properties to ignore, it's not a big deal, but in more complex structs, it can be a large number of properties that match it's name, so it would be great to have something as Augusto described in the @Mapper annotation, or even in the @Mappings annotation such as:

// ...
    @Mapper(ignoreByDefault=true)
// ...

or...

// ...
    @Mappings(ignoreByDefault=true, {
            @Mapping(source = "noun", target = "customerNoun"),
// ...

Regards!

Activity

  1. sjaakd commented on Mar 10, 2018

    @sjaakd
    Contributor

    @mowcixo if you want something like this, I would prefer the @BeanMapping iso @Mappings. In java8 @Mappings is marked by @Mapping as @Repeatable. @BeanMapping is there as holder specific for bean mapping methods.

    One solution might be: you could separate the ignore mappings into a specific mapper, lets say for the sake of the example: LenientMapper. The main mapper (MainMapper) could include a uses relation to the LenientMapper. The LenientMapper would have the following mapper definition: @Mapper( unmappedTargetPolicy = ReportingPolicy.IGNORE). You could even work with object graphs like this:

    So:

    @Mapper( uses = LenientMapper.class)
    public interface MainMapper {
       EntityWithMandatoryProps map(SourceDto in);
       NestedEntityWithAllMandatoryProps map( NestedSourceDto in);
    }
    
    @Mapper( unmappedTargetPolicy = ReportingPolicy.IGNORE)
    public interface LenientMapper{
      NestedEntityWithDefaultIgnoredProps map( NestedSourceDto in);
    }

    WDYT?

  2. sjaakd commented on Mar 17, 2018

    @sjaakd
    Contributor

    @mowcixo : I added an example based on the approach above. (see here). However, you would still have to ignore name based mappings explicitly.

    However: would this approach offer a solution for you?

  3. mowcixo commented on Mar 19, 2018

    @mowcixo
    Author

    @sjaakd thanks for the examples!

    So, thinking in my case, I would need an intermediate class that only have the fields I need, and use it to fill the final class? I think it could work.

  4. sjaakd commented on Mar 19, 2018

    @sjaakd
    Contributor

    I think it could work.

    Let me know. As the example points out: there's a difference between 'ignore' and 'not warn" for unmapped target properties. If you have implicit mappings (so source and target have the same name), MapStruct will map them and you'll still have to ignore them manually.

    I'm working on a PR to do a complete ignore. But that's work-in-progress.

  5. self-assigned this
    on Mar 19, 2018
  6. added 3 commits that reference this issue on Mar 19, 2018
  7. added this to the milestone on Mar 31, 2018
  8. added a commit that references this issue on Apr 8, 2018
  9. added 2 commits that reference this issue on Apr 18, 2018
  10. added a commit that references this issue on Apr 21, 2018
  11. sjaakd commented on Apr 21, 2018

    @sjaakd
    Contributor

    implemented..

  12. mowcixo commented on Apr 23, 2018

    @mowcixo
    Author

    @sjaakd Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions