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.)
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.
In the return value, `name` has been changed to `package`,
and `vConstraint` is now `versionConstraint`.
`constraint.package` is better than `constraint.name`, where
`constraint` is a PackageConstraint. It's also more consistent
with functions like parsePackageAtVersion which return an object
like `{package, version}`.
`vConstraint` was too cryptic.
Changes were discussed with Glasser in a code review.
Troposphere does not call parseConstraint or work with constraint
objects, so it doesn't need to change.
This is a breaking change to the package-version-parser API (or one
method of it, at least), but it is considered an internal API so we
are not worrying too much about it.
Summary:
Previously, the MongoConnection constructor (which gets called
implicitly the first time you make a Mongo.Collection) would wait for a
successful connection before returning ... if an oplog URL is supplied.
If not in oplog mode, it would return before the connection is
successful, and the first subsequent calls that actually tried to do
something with the DB would block instead.
Having an inconsistent API that is sometimes sync and sometimes async is
not very clear. Moreover, error handling from connect was strange.
Prior to 0.8.1 (24a0006c), connect errors would be thrown
uncatchably (ie, from an unrelated context). Starting with 0.8.1,
connect errors would effectively be ignored due to the new
bindEnvironment (they'd be logged, but all code would continue
normally).
It's pretty important that startup connection errors crash the server
process instead of letting it keep running unproductively. And it would
also be nice if those errors could be caught (if you're making a
MongoConnection in your own code). So this change ensures that
connection errors get thrown by the MongoConnection constructor.
Fixes#3038.
Test Plan: new unit test. manual test with MONGO_URL=xxx
Reviewers: ben
Subscribers: justinsb
Differential Revision: https://phabricator.meteor.io/D19
Summary:
What I'm looking for here is: attention to the few parts that aren't just
deletions (eg in auth.js), and thoughts about if removing any of these things
might break systems I haven't thought about.
Test Plan: test-packages, self-test (which mostly passes)
Reviewers: ekatek
Differential Revision: https://phabricator.meteor.io/D18
Nothing ever made full use of the promise of the complexity of the
API (configuration that can change at runtime) anyway.
This includes completely ignoring the $APP_CONFIG variable.
I opened GitHub issues against the only Atmosphere packages that had
dependencies on application-configuration (none of which actually used
the package other than by declaring the dependency).
Also remove SIGHUP handler. This was designed for a legacy system, and
SIGHUP would be a better fit for what autoupdate currently uses SIGUSR2
for. This includes removing some code in the ddp server to close
sockets on SIGHUP.
A recent change fixed the behavior of `Template.currentData`
and `Template.parentData` in event handlers and helpers.
These are tests for the new, correct behavior.
(The old behavior read the data of the template instance.
The new behavior read the data context around the DOM node
where the event or helper ran)
