Closed DCjanus closed 3 weeks ago
@shenqidebaozi feel free to comment something if you want
I have communicated with @shenqidebaozi about this PR through other channels, and I'd like to sync the discussion content here:
@shenqidebaozi believes that With
method should enough to be exposed to LogHelper.
But I think the With
method is not a lightweight operation (it requires copying an entire list), and providing an easily callable With
method might lead users to misuse it; exposing only the Logger
method can encourage users to reuse Logger instance. And @shenqidebaozi agreement with that.
@shenqidebaozi Hi, would you mind to take a look on this PR, maybe it's time to merge this
Description
In the real world, some log fields have significant contextual relevance. A reasonable approach is to use
log.With
to attach fields and create a newLogger
, then convert it to*log.Helper
held by an object.For statically created Loggers, this works well; but for dynamically created Loggers, such as when an API request contains a user ID and we perform many operations for it, in order to easily query logs afterwards, we need to include his user ID at each logging point.
Because Service objects generally only contain
*log.Helper
, there is currently no public method to obtainlog.Logger
from*log.Helper
and add fields, and we have to pass all those fields to every logging point, which is quiet boring.Show case