Oplog support with findOne

[wildhart]

Using montiapm I noticed that lots of the findOne() calls within my reactive publications were not using oplog because they didn’t specify a sort option:

I fixed that by adding the sort option, but now is says that oplog isn’t supported because I need to upgrade to Meteor 0.7.2 or later. But I’m using the latest 1.8.1!

I know that oplog is supported because the final find() at the end of the subscription uses oplog:

I’m deploying with MUP and oplog IS enabled. Why does it think that oplog isn’t supported @zodern, do you have any idea?

[zodern]

It’s nice to see the new nested events being useful. The observeChanges would never have been recorded in the past.

The agent only records the first reason it finds, and the checks for old versions of Meteor is broken with newer Meteor versions. With all of the checks working, it should have shown:

{
    code: "OPLOG_SUPPORTED",
    reason: "This query should support oplog. It's weird if it's not.",
    solution: "Please contact Kadira support and let's discuss."
  };

Reactive publications also require the ordered option to be set for findOne to use the Oplog: https://github.com/peerlibrary/meteor-reactive-mongo#reactive-queries-and-polling-vs-oplog

Since the agent only supports Meteor 1.4 and newer, I will remove the oplog checks for old versions of Meteor and look into adding one for using findOne with reactive publish.

[wildhart]

Hi @zodern

I’ve tried adding the ordered: true parameter but it’s still not using oplog. Tested on localhost and in production with this publication:

Meteor.publish('testReactive', function() {
	this.autorun(() => {
		const user = Meteor.users.findOne(this.userId, {
			fields: {"emails.address": 1},
			sort: {_id: 1},
			ordered: false
		});
		console.log('publish testReactive', user);
		return Meteor.users.find({_id: this.userId}, {
			fields: {"emails.address": 1}
		});
	});
});

Here’s a link to the result, the findOne() doesn’t use oplog but the find() does.

Does ordered still work?

[wildhart]

Hi @zodern, thanks for the repro via PM which shows oplog working correctly with my above publication.

By comparing the package versions with my own non-oplog-using app I tracked it down to reactive-mongo@0.2.2 compared to @0.3.0 you were using.

@mitar, I’ve raised a bug with peerlibrary:reactive-publish to update the default dependency.

[wildhart]

Now that I have the oplog working, I’ve patched findOne to do this:

// patch findOne so that it can use oplog by explicitly stating sort & ordered parameters
const _origFindOne = Mongo.Collection.prototype.findOne;

Mongo.Collection.prototype.findOne = function() {
	if (!arguments[1]) arguments[1] = {sort: {_id: 1}};
	else if (!arguments[1].sort) arguments[1].sort = {_id: 1};
	arguments[1].ordered = false;
	return _origFindOne.apply(this, arguments);
}

Seems to be working OK so far in testing. Probably achieves what this bug with meteor-reactive-mongo is asking for.

Does anyone know if there could be hidden side-effects of doing this?