API rewrite of MongoDb - breaking rawCollection usage since version 2.6

help
1

I’ve just updated from 2.2.1 to 2.7.1 only to run into a lot of problems with a bulk of depreciation messages and writeConflicts.

To quote from the changelog of version 2.6:

  • update/insert/remove behavior is maintained in the Meteor way, documented in our docs, but we are now using replaceOne/updateOne/updateMany internally. This is subject to changes in the API rewrite of MongoDB without Fibers AND if you are using rawCollection directly you have to review your methods otherwise you will see deprecation messages if you are still using the old mongodb style directly.

Do I understand it correctly that the changes to update, insert and remove behavior will eventually be rolled back once the MongoDb API is rewritten without Fibers?

What was the reasoning to go away from the official MongoDb syntax and come up with this distinction between one doc or many docs for the CRUD operations?

Secondly, has anyone who is also using the rawCollection extensively (like in my project) also experienced a sudden influx of writeConflict errors?

Additionally the check of result.nModified is no longer working:

TypeError: Cannot read property 'nModified' of undefined
2

Short answer: No. Longer answer: Mongo Package Async API by filipenevola · Pull Request #11605 · meteor/meteor · GitHub

It was MongoDb that changed the syntax. If you see a deprecation error for update, that means you are using a Collection.rawCollection().update somewhere. Meteor preserved the use of Collection.update until PR11605 above

Because result is undefined. Check why it is undefined

3

If I’m not wrong, you mean the nodeJS driver of MongoDb changed the syntax, right? Because the official MongoDb docs still show the “old” syntax

Yes and result is working fine since years in our production system. I haven’t done anything else than upgrading to version 2.7.1 which breaks our code.

I have since downgraded to 2.5.6 which is the last version before these changes to the MongoDb driver are made. And guess what, result immediately works again :wink:

This is a big showstopper for us.

4

That link is to the Mongo shell syntax, not the Node driver interface – they might not necessarily match 1-to-1. Even for the Mongo shell, though, the very top piece of information on that page says this:

Deprecated mongosh Method
This method is deprecated in mongosh . For alternative methods, see Compatibility Changes with Legacy mongo Shell.

The compatibility changes page, in turn, suggests switching to updateOne, updateMany, findOneAndUpdate, or bulkWrite.

Anyway – you’re surely seeing more deprecation warnings due to the updated MongoDB Node driver, which got bumped from v3.6.10 to v4.3.1 in Meteor 2.6. I’m sure this can be annoying if using rawCollection() heavily, since it’s a major/breaking version change in the driver version, but the deprecation + renaming is all coming from the native MongoDB driver itself, not from the Meteor wrapper.

As a result, it’s unlikely the Meteor team can (or should) make changes to restore the old behavior. The most plausible fix would be downgrading the driver version back to v3.x, but it’s not realistic to do that – ultimately, the driver version does need to be upgraded from time to time so that it stays current and supported. They tried to preserve compatibility with the old methods for those using Meteor’s MongoDB interfaces (which I appreciate), but for those of us using rawCollection(), we’re kind of on our own whenever the driver itself has a breaking change.

Here’s the interface reference for MongoDB driver v4.3 – you can see that update is marked as “deprecated” here in the official docs.

For the other issues you mentioned, I am not really sure about the cause, but it’s probably a good idea to review this migration guide if using the raw driver heavily in your app: Migration Guide for Node MongoDB Driver v4.x. Maybe there will be something relevant there?

(Note that I’m not affiliated with Meteor in any way and am not speaking on their behalf; I just joined this thread because I’m curious about all changes related to MongoDB syntax, especially with the upcoming move away from Fibers. Sorry to hear this upgrade was painful! I feel your pain; it can be quite frustrating to suddenly be forced to update lots of code across your codebase unexpectedly due to some breaking interface change.)

2 Likes
5

The first part of the page that you linked already mentioned that it has been deprecated.

I am not sure how we can help further as we do not even know where result comes from :slight_smile:

1 Like
6

You’re up very early, right?

It comes from here:

const numUpdates = await GroupsRaw.update(
            { _id: tgId },
            { $unset: { removed: '' }, $set: { updatedAt: new Date() } },
            { session: mongoSession },
        );
        if (numUpdates.result.nModified === 0) {
            throw new Error(
                `Warning - Something is wrong in unsetRemoved - No doc was being updated - tgId: ${tgId}`,
            );
        }

Once I’ve downgraded to Meteor version 2.5.6 it works fine as it was before. So there are more things breaking than just deprecated CRUD operations with version 2.6 and above.

Yet, I didn’t see that this is mentioned anywhere in the docs.

7

Check the value of numUpdates. I don’t use it but I am surprised there is a result intermediary key under numUpdates and that was working with older versions

1 Like
8

Thanks for the suggestion, RJ. It’s a bit ancient code (in an app that was started 6 years ago) so it might be from MongoDb 2.6 or even earlier. Will take it out as it has long fulfilled its purpose long ago, there are “only” 30 code references.

1 Like