Meteor 2.6-beta.4 was released today and we need your feedback

announce
41

I think from an API perspective, if meteor passed all options to the native functions transactions would just work - I think some of meteors functions strip out most options (e.g., insert/remove don’t allow options at all - I thought that update/find stripped certain options, but it looks like in more recent versions of meteor they don’t - so that would be a good starting point (transactions really just require a session per operation).

This way you don’t have to pick and chose between native functionality and schema validation, after hooks, redis-oplog notifications, etc

2 Likes
42

We’ve published Meteor 2.6-rc.1 yesterday. Probably the last one.

This version also includes a fix for Windows: Fix resolving npm deps of local packages when on different drive.

Changelog preview.

BTW, we are running with this new driver a few production apps that we have since the first beta versions, like atmosphere and https://cloud.meteor.com/

Cloud is a very nice validation as it connects to multiple databases in different ways, not only using the MONGO_URL in the standard Meteor way.

1 Like
43

Here is an interesting article on how to achieve some transaction guarantees without transactions: Transactions vs Two-Phase commit

Of course, I have no idea what Meteor users are actually doing in the wild.

3 Likes
44

Meteor 2.6 has been released! :tada:
Thanks to everyone that helped us test and refine this release.

8 Likes
45

Thank you all.

We will wait a few days before recommending it to everybody, but we already use it in our systems.

2 Likes
46

Has Meteor 2.6 been tested with redis-oplog?

47

hi @filipenevola , We are currently testing Meteor 2.6 (with MongoDB 4.4.10) in our development environment and it seems the new MongoDB driver is unable to connect to a MongoDB Docker.

Meteor 2.6 seems to fetch host info from the MongoDB Docker network instead of using just MONGO_URL value.

The error we are getting is:
MongoServerSelectionError: getaddrinfo ENOTFOUND 07e6d85eafb8

The 07e6d85eafb8 is our MongoDB docker container name and we are not sure why Meteor is trying to use that, whereas our MONGO_URL points to a localhost with a mapped/exposed IP from the MongoDB docker like as follows:

MONGO_URL=mongodb://127.0.0.1:27019/database

The issue above happens specifically only for Meteor 2.6.

Is this kind of set up no longer supported?

48

Hello, @arpee.
I’ve just done a simple MongoDB Docker environment exposing the port as you said and I can access it normally by passing the MONGO_URL to my meteor 2.6 application.
Are you sure that there aren’t any env vars or code overriding this behavior?

There weren’t any changes related to parsing MONGO_URL on Meteor 2.6. If you are still having issues, please open a Github issue so we can follow up better.

1 Like
49

Not directly, but no breaking changes are expected. Redis-oplog is not using any rawCollection method, and is also not depending on mongo oplog.

1 Like
51

hi @renanccastro

Our meteor app is outside the docker network where MongoDB Docker is in.

Apparently the cause is the Service Discovery feature of the driver.

To those who have a dev/testing instance similar to ours (experiencing the same error) wherein our MongoDB is inside Docker, exposed via a port, and the meteor app is not in the docker network, the quick fix is to use the directConnection option like so:

MONGO_URL=mongodb://127.0.0.1:27019/database?directConnection=true

4 Likes
52

That’s intriguing. I did set up the same environment as yours and did not have this behavior. Anyway thanks for digging deeper into this.

It’s valuable information, I will add it to our docs, thanks!

53

@renanccastro when you tested the simple MongoDB docker environment, were you using MongoDB 4 or 5? I wonder if this is related to useUnifiedTopology which is now set to true in MongoDB 5

54

I was using 5.0.6 indeed

55

But I also can’t repro on 4.4.12, same environment.

56

We’ve published mongo@1.14.1.

If you run meteor update in your project using 2.6, you should be able to use this version of mongo package.

Fixes this issue.

2 Likes
57

Awesome, I was having an issue with subscriptions after updating to 2.6 and mongo@1.14.1 fixed that!

Thank you so much for your team’s hard working in getting Meteor ready for Mongo 5, and thank you to all of the community who took the time to test the beta versions and provide feedback. You’re all heroes in my book! :muscle::1st_place_medal:

3 Likes
58

In testing v2.6 today I came across a new issue where an array field in a document is converted to an object.

I’ve reproduced this in a simple app and reported the issue here:
https://github.com/meteor/meteor/issues/11887

3 Likes
59

Thanks again for reporting.

We have released a fix for this issue on mongo@1.14.2

If you run meteor update in your project using 2.6, you should be able to use this version of the mongo package.

4 Likes
60

Seems we’re now on version 1.14.6 - keep up the good works, thanks!

1 Like
61

There is a problem with the fields attribute in subscriptions that is not considered when the data is published. Now, all fields in a collection are published to the client. This could be a security problem because all user data is sent to the client. As a workaround I have overridden the _getFindOptions of the Mongo Collection:

Mongo.Collection.prototype._getFindOptions = ((func) => {
        return function (options) {
            const findOptions = func.call(this, options);
            if (findOptions.projection) {
                findOptions.fields = findOptions.projection;
            }
            return findOptions;
        };
    })(Mongo.Collection.prototype._getFindOptions);

I am waiting for the change to be made in the redis-oplog package so that projection is considered instead of fields.