Rework how we store log fields #81
Conversation
| result := make([]string, 0, len(maps[0])) | ||
|
|
||
| for k := range maps[0] { | ||
| result = append(result, k) | ||
| } | ||
|
|
||
| return result |
There was a problem hiding this comment.
If we wanted to be really fancy here, we could declare our own type FieldMap map[string]interface{}, which would give us a concise way to refer to these maps, and put this particular code into a Keys() method but really like not at all important or necessary to do! 😄
There was a problem hiding this comment.
Will create a follow up to have tailor made types like FieldMap and FieldMaps.
…field maps"
"Field maps" are `map[string]interface{}`, that carry additional fields we want the logging library to attach to logs
… options This is what gets stored in the context with each log, and will now carry the fields we want to append to logs directly (as a map), instead of relying on the `hclog` `ImpliedArgs` facility.
…fields This doesn't change the interface of the library, but it changes where the fields are stored before they are logged.
Just shortcuts for go commands
detro
force-pushed
the
detro/75-rework_how_we_store_log_fields
branch
from
492f8dc
to
118690f
Compare
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
Closes #75