| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Remove leading comments that are just stating the filename.
Move any file-level comments below the copyright banner.
Remove leading blank lines.
|
| |
|
|
| |
class
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
It's slightly different than that on DocumentSource, which should be
more obvious.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
explain
Like other explainable commands, aggregate can now be
explained using the explain command, e.g.
db.runCommand({explain: {aggregate: ...}, verbosity:
"executionStats"}). The existing explain:true flag
corresponds to "queryPlanner" mode and is still supported.
However, explain:true cannot be specified when explaining
aggregate via the explain command.
Additional execution information is provided only in the
$cursor section of the aggregation explain output. Having
aggregation stages themselves track and report execution
info is further work.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These methods were formally used to propagate a new ExpressionContext to
stages, accumulators, or expressions which potentially needed to
comparisons. Originally, this was necessary since Pipeline parsing
happened outside of the collection lock and thus could not determine if
there was a default collation on the collection. This meant that the
collation could change after parsing and any operators that might
compare strings would need to know about it.
We have since moved parsing within the lock, so the collation can be
known at parse time and the ExpressionContext should not change. This
patch requires an ExpressionContext at construction time, and disallows
changing the collation on an ExpressionContext.
|
| | |
|
| |
|
