Emit warnings for precision loss #5

Open
gunnarmorling opened this Issue Mar 2, 2013 · 11 comments

Projects

None yet

5 participants

@gunnarmorling
Member

This follows up on #1; If built-in conversion causes a possible precision loss (e.g. from long to int), a warning or error should be created. If the concerned attribute is mapped via @Mapping the marker should be at the annotation, otherwise at the mapping method(s).

It might be a good idea to make it configurable either globally and or via an attribute in @Mapper whether the error kind should be WARNING or ERROR.

@lesaint
lesaint commented Nov 5, 2014

Hi @gunnarmorling,

I am wondering here, what are the options for the developer once an error or a warning was raised?

Either the developer is ok with the precision-loss, then how does she get rid of the warning/error?
Either the developer is not ok with it, then how does she fix it?

I don't know MapStruct all that well so I might be missing an obvious answer.

@sjaakd
Contributor
sjaakd commented Nov 5, 2014

@Lasaint, mapping methods overrule type conversions and builtinmehods . So if you detect a precision loss, you can decide to use a handwritten mapping method.

@lesaint
lesaint commented Nov 5, 2014

ok, thanks for the reply @sjaakd

@gunnarmorling
Member

Either the developer is ok with the precision-loss, then how does she get rid of the warning/error?

Hi @lesaint, we haven't thought about it in detail, but I could envision the following

  • By default, raise a build time error (or warning; there'd probably be a global setting for this) in case the type of a target property may not carry all possible values from the source property
  • For the (likely rare cases) where you are ok with a possible value loss, there could be a new attribute on @Mapping such as acceptPotentialValueLoss()=true. This would allow to suppress the error on a per-case basis (which I think is what makes most sense as the situation almost always is problematic). Alternatively, you could define a custom method such as byte intToByte(int i) which then would be applied as @sjaakd is saying, but that'd be of more global nature.

Either the developer is not ok with it, then how does she fix it?

They'd have to change the type of the target property to accept the source property without loss.

@gunnarmorling gunnarmorling modified the milestone: 1.0.0.RC1, 1.0.0.Beta3 Nov 19, 2014
@gunnarmorling gunnarmorling modified the milestone: 1.0.0.RC1, 1.0.0.Beta4 Mar 1, 2015
@gunnarmorling gunnarmorling modified the milestone: 1.1-next, 1.0.0.CR1 May 29, 2015
@GuiSim
GuiSim commented Jan 17, 2017

Any progress on this feature? I think it would be a great addition to MapStruct.

@agudian
Member
agudian commented Jan 19, 2017

No one worked on this, yet. Would you maybe like to give it a try?

@gunnarmorling
Member

As @agudian is saying, any help with this would be welcome. I'd be very glad to see it in :) We can give directions to get started if needed.

@GuiSim
GuiSim commented Jan 19, 2017

Thanks for the proposition. We're still unsure if we're going to go ahead with MapStruct but if we do, I'd love to contribute back to the project as I think we'll need this feature.

I'll update if we choose MapStruct!

@gunnarmorling
Member

Sure; if you have any questions during your decision process, let us know, we'll be glad to help as good as we can.

@gunnarmorling
Member

Hey @GuiSim, curious which route you did end up following? If you didn't go for MapStruct in the end, do you mind me asking what spoke against it? Always eager to learn from people's thinking so we can improve the stuff. Thanks!

@GuiSim
GuiSim commented Feb 17, 2017

We didn't go with any mapping technology for now.. we're still writing what we call "translators" to convert from one type to another.

It's still a tedious process but we're slowly removing intermediary objects. We realize that this increases coupling but we feel like the pros outweigh the cons.

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