[SERVER-83553] Support unique_ptr and shared_ptr in logv2 Created: 23/Nov/23 Updated: 28/Nov/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Ivan Fefer | Assignee: | Backlog - Service Architecture |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Service Arch
|
| Participants: |
| Description |
|
Sometimes for debug or logging purposes we need to output a container of smart pointers. It would be convenient to support this in our logv2 library |
| Comments |
| Comment by Billy Donahue [ 28/Nov/23 ] |
|
I have a few concerns about introducing these inside logv2 directly. My preference would be to introduce a loggable proxy type that can be logged. This proxy type would be customizable to the needs of the caller. This way we don't have to try to find a one-size-fits-all generic solution and embed it into logv2. We don't log raw pointers, so I I'm concerned about the expectation that they would be loggable if some smart pointers are loggable. Lots pointer-like types are missing from the discussion, notablly T*. When logging a pointer, is the intent that the pointer value appear in the log or that the pointee should be serialized into the log? If the pointee cannot be serialized, logging the pointer will be invalid, and perhaps should not be. We try not to "leak" exact pointer values in the log at all in production, as a security measure. A pointer can be a polymorphic, unlike an optional. So there are some issues here about how to stringify through a polymorphic interface. I don't really want to try for a generic solution for that problem, as it's perhaps best handled by the caller of LOGV2. Analogy to boost::optional breaks down a bit, because we have historically used boost/optional_io.hpp and optionals were loggable with operator<<, but we don't do that anymore, and use util/optional_util.h instead, for API compatibility with std::optional. So supporting them the way we are is bit of a concession to that legacy. |