-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Support multi-field encoding using zap.Inline #912
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov Report
@@ Coverage Diff @@
## master #912 +/- ##
=======================================
Coverage 98.26% 98.27%
=======================================
Files 44 44
Lines 1965 1970 +5
=======================================
+ Hits 1931 1936 +5
Misses 27 27
Partials 7 7
Continue to review full report at Codecov.
|
abhinav
reviewed
Feb 11, 2021
Fixes #876 Currently, a `zap.Field` can only represent a single key-value. Add `zap.InlineObject` so to allow adding multiple fields to the current namespace from a type implementing `zap.ObjectMarshaler`. This also solves a more general problem: a single `zap.Field` can now be used to add multiple key/value pairs.
abhinav
approved these changes
Mar 4, 2021
abhinav
approved these changes
Mar 22, 2021
prashantv
changed the title
Support multi-field encoding using zap.InlineObject
Support multi-field encoding using zap.Inline
Mar 23, 2021
abhinav
added a commit
that referenced
this pull request
May 25, 2021
Although the values of the FieldType enums aren't part of the Zap contract, changing existing values is still a risky change. [apidiff] considers this a brekaing change. ``` Incompatible changes: - BinaryType: value changed from 3 to 4 - BoolType: value changed from 4 to 5 - ByteStringType: value changed from 5 to 6 - Complex128Type: value changed from 6 to 7 - Complex64Type: value changed from 7 to 8 - DurationType: value changed from 8 to 9 - ErrorType: value changed from 26 to 27 - Float32Type: value changed from 10 to 11 - Float64Type: value changed from 9 to 10 - Int16Type: value changed from 13 to 14 - Int32Type: value changed from 12 to 13 - Int64Type: value changed from 11 to 12 - Int8Type: value changed from 14 to 15 - NamespaceType: value changed from 24 to 25 - ReflectType: value changed from 23 to 24 - SkipType: value changed from 27 to 28 - StringType: value changed from 15 to 16 - StringerType: value changed from 25 to 26 - TimeFullType: value changed from 17 to 18 - TimeType: value changed from 16 to 17 - Uint16Type: value changed from 20 to 21 - Uint32Type: value changed from 19 to 20 - Uint64Type: value changed from 18 to 19 - Uint8Type: value changed from 21 to 22 - UintptrType: value changed from 22 to 23 ``` [apidiff]: https://github.com/golang/exp/blob/master/apidiff/README.md Again, although maintianing these values is not part of the Zap contract, in the interest of erring on the side of safety, I'm moving the new FieldType (added in #912) to the bottom to avoid changing the values of the other items.
abhinav
added a commit
that referenced
this pull request
May 25, 2021
Although the values of the FieldType enums aren't part of the Zap contract, changing existing values is still a risky change. [apidiff] considers this a brekaing change. ``` Incompatible changes: - BinaryType: value changed from 3 to 4 - BoolType: value changed from 4 to 5 - ByteStringType: value changed from 5 to 6 - Complex128Type: value changed from 6 to 7 - Complex64Type: value changed from 7 to 8 - DurationType: value changed from 8 to 9 - ErrorType: value changed from 26 to 27 - Float32Type: value changed from 10 to 11 - Float64Type: value changed from 9 to 10 - Int16Type: value changed from 13 to 14 - Int32Type: value changed from 12 to 13 - Int64Type: value changed from 11 to 12 - Int8Type: value changed from 14 to 15 - NamespaceType: value changed from 24 to 25 - ReflectType: value changed from 23 to 24 - SkipType: value changed from 27 to 28 - StringType: value changed from 15 to 16 - StringerType: value changed from 25 to 26 - TimeFullType: value changed from 17 to 18 - TimeType: value changed from 16 to 17 - Uint16Type: value changed from 20 to 21 - Uint32Type: value changed from 19 to 20 - Uint64Type: value changed from 18 to 19 - Uint8Type: value changed from 21 to 22 - UintptrType: value changed from 22 to 23 ``` [apidiff]: https://github.com/golang/exp/blob/master/apidiff/README.md Again, although maintianing these values is not part of the Zap contract, in the interest of erring on the side of safety, I'm moving the new FieldType (added in #912) to the bottom to avoid changing the values of the other items.
abhinav
pushed a commit
that referenced
this pull request
May 25, 2021
Fixes #876 Currently, a `zap.Field` can only represent a single key-value. Add `zap.Inline` to allow adding multiple fields to the current namespace from a type implementing `zap.ObjectMarshaler`. This also solves a more general problem: a single `zap.Field` can now be used to add multiple key/value pairs.
abhinav
added a commit
that referenced
this pull request
May 25, 2021
Although the values of the FieldType enums aren't part of the Zap contract, changing existing values is still a risky change. [apidiff] considers this a brekaing change. ``` Incompatible changes: - BinaryType: value changed from 3 to 4 - BoolType: value changed from 4 to 5 - ByteStringType: value changed from 5 to 6 - Complex128Type: value changed from 6 to 7 - Complex64Type: value changed from 7 to 8 - DurationType: value changed from 8 to 9 - ErrorType: value changed from 26 to 27 - Float32Type: value changed from 10 to 11 - Float64Type: value changed from 9 to 10 - Int16Type: value changed from 13 to 14 - Int32Type: value changed from 12 to 13 - Int64Type: value changed from 11 to 12 - Int8Type: value changed from 14 to 15 - NamespaceType: value changed from 24 to 25 - ReflectType: value changed from 23 to 24 - SkipType: value changed from 27 to 28 - StringType: value changed from 15 to 16 - StringerType: value changed from 25 to 26 - TimeFullType: value changed from 17 to 18 - TimeType: value changed from 16 to 17 - Uint16Type: value changed from 20 to 21 - Uint32Type: value changed from 19 to 20 - Uint64Type: value changed from 18 to 19 - Uint8Type: value changed from 21 to 22 - UintptrType: value changed from 22 to 23 ``` [apidiff]: https://github.com/golang/exp/blob/master/apidiff/README.md Again, although maintianing these values is not part of the Zap contract, in the interest of erring on the side of safety, I'm moving the new FieldType (added in #912) to the bottom to avoid changing the values of the other items.
cgxxv
pushed a commit
to cgxxv/zap
that referenced
this pull request
Mar 25, 2022
Fixes uber-go#876 Currently, a `zap.Field` can only represent a single key-value. Add `zap.Inline` to allow adding multiple fields to the current namespace from a type implementing `zap.ObjectMarshaler`. This also solves a more general problem: a single `zap.Field` can now be used to add multiple key/value pairs.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #876
Currently, a
zap.Field
can only represent a single key-value. Addzap.Inline
to allow adding multiple fields to the currentnamespace from a type implementing
zap.ObjectMarshaler
.This also solves a more general problem: a single
zap.Field
can nowbe used to add multiple key/value pairs.