Now they are methods on a compiled Matcher rather than doing their own
operator parsing from scratch. This means less work is happening for
each oplog entry, and it also localizes knowledge about selector
parsing.
Previously, $near was only used in the absence of a sort specifier; now,
it's also used as a tie-breaker when there is a sort specifier. (Tested:
this matches MongoDB.)
Big minimongo refactoring. Lays the groundwork for trusting more
selectors in oplog and implementing the '$' option to updates, though
neither are yet implemented.
The idea will be that "selector" will always mean the EJSON
representation of a selector, and "matcher" will be some compiled
form (whether Minimongo.Matcher or the various lambdas that make it up)
Now selectors don't have a link to the internals of the cursor; instead,
Selector.documentMatches() return values can include a 'distance' field. (This is
the dress rehearsal for also adding an 'arrayIndex' field.)
Contexts that run selectors and may need to sort later now explicitly
keep around a distances IdMap. Specifically, the handles associated with
observeChanges calls each have a distances IdMap, and the _getRawObjects
call has a temporary one (which might alias one of the
observeChanges-related ones if it's being called from observeChanges,
either for the initial query or to re-compute).
Implement branching for $near (not quite the way Mongo does it, but
better than nothing)
That was the last $operator to be moved to the new model, so I could
delete a lot of obsolete stuff.
Instead of having a semi-implicit dependency on the cursor, specify
distances explicitly when "instantiating" the comparator.
The next refactoring will remove _distance from cursor entirely.
Fixes two incompatibilities:
- {$exists: false} did the wrong logic when there were multiple branches
(we (poorly) special-cased $not and $nin but not this negative case)
- No longer require the argument to $exists to be a boolean;
{$exists: 0} and {$exists: 1} should work, eg
