This bug was introduced by #4694 which switched OplogObserveDriver's
listener from using beginWrite to the new onBeforeFire. beginWrite
doesn't throw an error when called on a retired fence; onBeforeFire
does. So don't try to interact with fired fences. (I'm not sure if
there is an importance to the distinction between retired and fired
introduced by dcd26415f, but this code should be fine.)
While we're at it, make the error in question (which shouldn't happen)
be delivered to Mongo write callbacks (or thrown), if for no other
reason than that it allows us to test this fix.
Fixes#4839.
We've been shipping the `logging` package to the client even though it
isn't used on the client by any core packages. Now that the `logging`
package is removable from your app, let's make it actually removable
by deleting totally worthless dependencies that exist for bizarre
historical reasons.
For example, some packages, like `reload` and `mongo`, depend on
`logging` because that's where `Meteor._debug` used to be, before it
was moved to the `meteor` package and `logging` was repurposed for
something else. The `ddp-server` package had a crazy overreaching set
of dependencies, pulling in a bunch of client-side libraries even though
it only has server-side code of its own.
JSON support is in all browsers we could conceivably care about; it's
ES5 and has perfect support in IE 8. No need to ship a library as
a core package, and no need to specify dependencies on it.
We could conceivably publish a new version of the `json` package that
is empty, so that apps using packages that still say `use("json")`
also get the code size reduction, but we'll wait until someone requests
that.
This included removing some internal version constraints. It would be
nice if package A could say "use B@2.0.0" (when both have changed), but
when they're both in the release, we need to make a release that has a
B@2.0.0-rc in it, which doesn't match that constraint. Fortunately,
constraints aren't necessary within a release anyway.
Before this change, number of catch-up attempts was N*M, where N is number of
writes inside of the fence, and M is number of active observers on affected collections.
Every catch up issues yet another query to find the latest oplog entry.
It was extremely inefficient, in terms of both CPU usage and added latency.
After executing write-heavy methods, application process was occupied for many seconds
doing the same thing over and over again.
This change provides a performance improvement for all kinds of workloads.
Closes#550.
`loginWithPassword` now matches username or email in a case insensitive manner.
If there are multiple users with a username or email only differing in case, a
case sensitive match is required.
Although `createUser` won't let you create users with ambiguous usernames or
emails, this could happen with existing databases or if you modify the users
collection directly.
Because MongoDB does not support case insensitive indexes, we perform a case
insensitive query both before and after inserting a new user, removing the user
when we detect another matching user has been inserted in the meantime. This
leaves us with the theoretical possibility that a server crash could occur in
between the insert and the second query or remove. In that situation there
would be two accounts with a username or email only differing in case, so we
will require a case sensitive login.
However, turns out the previous commit doesn't really work --- making
webapp a strong dependency of ddp-server means that as soon as we load
mongo we'll load webapp in the tool which is bad. So move the mongodb
Npm module out of mongo, since that's all we need in the tool.
For example, 5ddf203 stops us from understanding $sets and $unsets with
empty field parts, but pre-2.6 MongoDB could generate them. (And even
post-2.6 may be able to generate $unsets with bad field names, but it's
not important for us to match that behavior since with Minimongo you
shouldn't be able to put them in in the first place.)
Specifically, Mongo.Collection objects on the server now have
rawCollection and rawDatabase methods.
You can use MongoInternals.NpmModules.mongodb.version to tell what
version of the mongodb npm module is the backend for HTTP.call. This
version may change incompatibly from version to version of Meteor; use
at your own risk. (For example, we expect to upgrade from the 1.4.x
series to the 2.x series in the not-too-distant future.)
Fixes#3640.
Previously, the document would be transformed based on the first deny or
allow rule's transform, instead of using the matching transform rule.
This bug only applied to update, not insert or remove.
Technically one could do something fancy to avoid calling transform
unnecessarily if there are many validators with the same transform, but
if you're stressing that much about performance you might as well just
write a method instead of using allow/deny.
Fixes#3108.
In order to test this, we applied the following diff to
minimongo/selector.js:
--- a/packages/minimongo/selector.js
+++ b/packages/minimongo/selector.js
@@ -591,6 +591,8 @@ ELEMENT_OPERATORS = {
},
$in: {
compileElementSelector: function (operand) {
+ if (operand === null)
+ operand = [];
if (!isArray(operand))
throw Error("$in needs an array");
This means that minimongo now allows `$in: null`, and thus
OplogObserveDriver can be used for the query in the new 'bad query'
test, but mongod still returns an error that is processed by the passing
test. (The client side of the test fails with this temporary change,
because minimongo no longer throws!)
It's hard to see how to test this better, because minimongo should throw
on any queries that mongod throws on.
Fixes#2534.
In the past, a bad query would be retried forever, causing the
observeChanges to hang.
(In the common case of a DDP subscription, this would also cause the
current DDP connection to completely stop reading messages, and would
make methods that do writes to the same collection (on ANY DDP
connection) never get their 'updated' messages. See
https://github.com/meteor/meteor/issues/2534#issuecomment-73355050
These two secondary problems may still need to be fixed but at least
the root cause should be addressed.)
This only fixes PollingObserveDriver, not OplogObserveDriver, but this
issue typically only affects PollingObserveDriver because we don't
choose to use OplogObserveDriver when minimongo can't understand a
query.
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.
