-
-
Notifications
You must be signed in to change notification settings - Fork 271
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
use isReflectNil instead of isEmptyValue to gate Transformers #203
Conversation
Hello, @GGabriele! This is your first Pull Request that will be reviewed by SourceLevel, an automatic Code Review service. It will leave comments on this diff with potential issues and style violations found in the code as you push new commits. You can also see all the issues found on this Pull Request on its review page. Please check our documentation for more information. |
@GGabriele LGTM. All tests are green. |
@imdario Can we merge this, hitting this exact case trying to switch from using wrapper types to proto3 optional types and maintain the merging behavior I had before (can't replicate this transformer #207). We are essentially looking to write an an identical transformer to the author here. Unfortunately we didn't notice this until switching a bunch of stuff over. Don't even need it in a tagged release if that's too much right now I'll happily point at |
This builds on darccio#203 which attempted to provide a more flexible gating to running transformers. However upon testing darccio#203 in my own environment, I ran into the first panic listed below. There are a variety of errors that can happen when trying to run reflection on zero values: 2 just from my testing of this PR ``` panic: reflect: call of reflect.Value.Type on zero Value panic: reflect: call of reflect.Value.FieldByName on zero Value ``` The panic specifically calls out zero values, but it's actual a more specific set of values which is covered by `reflect.IsValid`. I attempted to replace the check with `reflect.IsZero`, which ends up being too restrictive and breaks existing tests. I also attempted to solely use `reflect.IsZero` which is not restrictive enough and cause the later panic above in the tests. Thus I arrived on the combination in this PR which seems to strike the "right" balance.
Nevermind my first comment, I found a bug in this change. I've put up an alternate PR (#211) that passes in my environment and the existing mergo tests. Attempting to add a test to catch that case |
@zaquestion I'll check it this evening. |
@GGabriele Closing this in favour of #211 |
Hi!
While using this great library, I came across a few issues mostly related to how
mergo
handles zero-values (#166). Based on the comments from various contributors, I decided to write a custom Transformer to handle my use-case as I wished, but then I realized it wasn't possible, as transformers are executed only if thedst
is not an "empty" value (https://github.com/imdario/mergo/blob/master/merge.go#L82-L87). Therefore, we cannot apply any transformer to values likefalse
,0
etc.What I'm proposing with this PR is to use isReflectNil instead of isEmptyValue to gate transformers execution.
Following is an example of the usage I'm envisioning:
Let me know what you think!