Fixes#2817. Regular Expressions in JavaScript keep the state when matching for
the same string. When there are two documents with the same value of the
matching field, the minimongo can incorrectly filter collection because regexp
would return different values on different calls.
This was originally introduced with
f1b77fec96, but it looks
like all of our tests now pass. (Maybe eliminating `rewind` in
b5a0613f85 made this no
longer necessary?)
If we find that this commit did break something, let's make sure to
add a failing test before reverting.
This reverts commit c05ae240af EXCEPT for
the "fetch in observe" test, which I'm leaving in because we still want
a test for #2275.
This commit made it an error to start an observeChanges from within an
observeChanges callback for the same collection, but it turns out that
this is actually a somewhat common thing to do (for example, nested
'each'). Instead, we'll leave things the way they were pre-0.8.2: you
can start an observeChanges from within an observeChanges callback, but
it'll be subtly buggy in that you won't get synchronous 'added'
callbacks. This issue is described in #2315, along with the fact that
insert/update/remove/resumeObservers won't run their affected observe
callbacks if they are called from within a task on the collection's
queue. Eventually we'll implement the full fix (which relaxes the
requirement that insert/update/remove run all their callbacks before
returning) described in #2315.
Make some instances of #2315 into errors instead of silent early
returns.
Specifically, observeChanges calls (with added or addedBefore callbacks)
from within another observeChanges callback on the same collection will
be unable to differentiate between initial and later added/addedBefore
calls, which is serious enough to be an error (see #2315 for details).
We don't currently think that the other effect of #2315 (where observe
callbacks triggered by insert/remove/update/resumeObservers will not
occur before those methods return, if they are called reentrantly) is
problematic enough to deserve this sort of error.
They used to run the query twice: once for the actual result and once to
set up the observe. Now it shares the work between the observe and the
actual query.
This required me to inline the _depend helper, but I actually think this
made what's going on more direct and clear.
Drop the _allow_unordered hack. I'm not convinced that it was ever truly
valid; the observe code really doesn't support unordered observes with
skip and limit, and I could not remember what it was about count's use
that made it hypothetically safe. Easier to just remove the hack (until
we maybe eventually actually fix#1643)
Stop using Deps.Dependency in an unidiomatic way; just use
Deps.currentComputation directly.
