[SERVER-33653] move currentOpTime field from op to top level of currentOp output Created: 05/Mar/18 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Eric Milkie | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query Execution
|
| Participants: |
| Description |
|
In |
| Comments |
| Comment by Eric Milkie [ 08/Mar/18 ] |
|
(The original name of "currentOpTime" was apparently intended to mean "currentOp Time", for "the time for this currentOp".) |
| Comment by Eric Milkie [ 08/Mar/18 ] |
|
It is, in fact, a wall clock time. |
| Comment by Andy Schwerin [ 08/Mar/18 ] |
|
The problem with current time is that it sounds like a wall clock time. What is the type of this field? If it excludes term, clusterTime might be the right name... |
| Comment by Eric Milkie [ 07/Mar/18 ] |
|
Yes please, the renaming of the field will be helpful. |
| Comment by David Storch [ 07/Mar/18 ] |
|
The modern implementation for gathering CurOp-related diagnostic data is the $currentOp aggregation stage, which returns a cursor rather than a single document. Therefore, there is no "top level" position where the currentOpTime field could live. We could, however, rename the field to currentTime, if we believe that this would reduce confusion. |