Since this file ends up getting copied into the server bundle, along with
files like boot.js, it makes sense to keep it with those files.
Renamed tools/shell/client.js to tools/shell-client.js for symmetry.
It's maybe possible that stop() yields, and in general is more complex.
Since the ObserveMultiplexer is already at the point where it will not
be able to start running again, we should remove it from the registry
first.
Now when we get an error from Mongo, the cursor description is included.
Other than by the test-only _resumePolling, _pollMongo is only called at
the top level of an async-queued task, so the previously thrown error
never did anything other than print the exception (from within
_SynchronousQueue) anyway.
Fixes#1633.
(See also #2534.)
Before this change, if the deletion failed the dev bundle
would get extracted into a subdirectory of METEOR\dev_bundle
rather than into that directory.
Note that shell/server.js is copied into the bundle as shell-server.js,
like before, however now it contains none of the extraneous code that
belongs in shell/client.js.
The original reason server and client code were combined in a single file
was to share helper functions and configuration variables (e.g.
getInfoFile and EXITING_MESSAGE). Now, shell/client.js requires
shell/server.js to access those shared exports.
Mongo 2.4 had the following behavior: if
c.update({_id: 'x'}, {y: 1}, {upsert: 1})
resulted in an insert, it would get a random _id instead of 'x'. (This
only happened when the update was a "replacement" rather than a
"modifier".) We dutifully implemented this behavior in various parts of
Meteor and added tests to prove that it occured.
However, this was actually a bug which got fixed in Mongo 2.6:
https://jira.mongodb.org/browse/SERVER-5289
Since this was regarded by Mongo as a bug (not a backwards-incompatible
change deemed worthy of mention in the Mongo 2.6 release notes), we
should just make Meteor always behave the Mongo 2.6 way, no matter what
version we're on (at least in the aspects where Meteor has its own code
to control this). In other parts of Meteor where the queries are just
getting processed by Mongo, the behavior of this special case will match
Mongo's behavior. If you care strongly about consistent behavior in
this strange edge case, upgrade to Mongo 2.6!
Specifically:
- The minimongo implementation of modifiers loses its special-case code
which drops _id from the modified document during an upsert replace.
- Mongo.Collection.update should only generate a random _id as an
insertedId if the selector doesn't mention one.
- The case of a selector mentioning _id and a *replacement* modifier
not mentioning _id should still count as "known ID" in the
lower-level MongoConnection.update, which means that there's no
reason to use simulated upsert and that we should include it as
insertedId in the return object.
- Various tests of the previous behavior should be changed.
(Note that if this commit is cherry-picked onto 1.0.3.1 (ie, run against
2.4), it would fail, because some of the tested cases end up going to
unsimulated Mongo upsert and assume the 2.6 behavior. That's OK, as
described above.)
Fixes#2278.
This fixes the "upsert error parse" test and changes the behavior of
other failing upsert tests to be failing with "Upsert failed after 3
tries" errors instead of failing with a "can't change _id"-style error.
First step of addressing #2278.
Previously, if a random exception was thrown in a self-test test (as
opposed to a specific TestFailure), it would crash the whole process and
not run any more tests. That's silly. It should just be a test
failure!
