@channel happy Friday to all I hope you are ready to enjoy your weekend.
Meteor 2.6-beta.4 was released today.
Why is this important?
Meteor 2.6 aims to update MongoDB Node.js Driver to 4.3.0 in order to be compatible with MongoDB 5.x. The support was initially discussed here.
beta.3 fixed an issue with oplog.
beta.4 merged 2.5.5 into Meteor 2.6 branch (yes, Meteor 2.5.5 was already released, with improvements in deploy speed due to compression changes in the tool, it is going to be recommended soon).
So please check your app behavior with Meteor 2.6-beta.4: meteor update --release 2.6-beta.4.
We’ve also started this draft for a Migration Guide to Meteor 2.6, of course, this MongoDB change is the big thing there. Please take time to read it and let us know what you think in the release PR.
Please provide your feedback about eventual issues or unexpected behaviors of your app in release PR as well.
Do I understand correctly that the NodeJS MongoDB driver was updated from 3.6 to 4.3? Then it changes the API of the underlying .rawCollection() objects (for the better). That would have repercussions on anybody using the MongoDB collections directly. Or am I missing something?
That’s right @aureooms, the MongoDB driver has been updated from 3.6 to 4.3. If you are using rawCollection or MongoDB directly in other ways, you should revise its methods and adapt them if necessary.
I was wrong with my initial assumption that this will not require much work if we are going to continue using MongoDB 4.x. I know that it is written there but there is a need to highlight the move of the MongoDB node driver from 3.x to 4.x with the same level of highlight of moving MongoDB 4.x to MongoDB 5.x (this mismatch of versioning also adds so much to the confusion).
For those who are not updating to MongoDB 5.0 soon, the breaking changes of the nodejs driver is a big gotcha.
Hello,
When I run meteor update : meteor update --release 2.6-beta.4
I have one package downgraded : mikowals:batch-insert downgraded from 1.2.0 to 1.1.9
Is this normal ?
Thanks
We will improve the organization of this migration guide to highlight the driver change as well.
It is not an easy spot for us as we didn’t break anything in Meteor, but at the same time, people using raw collection are going to be affected as MongoDB changed many things in the driver.
As you can check in the PR, we’ve done a lot of work to keep everything supported by Meteor working in the same way.
I understand your question, but I don’t think this is related to the thread here.
Meteor doesn’t support transactions as you are mentioning here indeed, so as you are using transactions directly from MongoDB Node.js Driver changes in the driver are going to affect you.
MongoDB changed many things that affected Meteor, but we could create compatibility versions to avoid affecting Meteor apps in the parts of MongoDB that Meteor offers support, which is not the case of Transactions.
We are open to suggestions on making this transition from Mongo Driver 3.x to 4.x as smooth as possible in terms of usages outside of Meteor support.
I’m not sure how we could help people using features that Meteor does not support. In this case, the work to make your code compatible with the new Mongo Driver would be the same with or without Meteor.
Remember that Atlas is also saying they will automatically change a few plans to MongoDB Server 5.x next month, so we need to make sure we support Mongo Driver 4.x.
Again, we are open to ideas to make this migration process better.
The question is indeed why Meteor isn’t supporting such an important feature like transactions. Quite frankly, I’m not sure how others are running their production systems without transactions or they don’t care about data integrity issues when operations fail and relations between documents are broken as some data was updated whilst others (after the error) wasn’t.
Still not having support for transactions in Meteor is a major downside IMO but it obviously depends who you want to focus on. If Meteor is just for people building quick demo versions and some small apps where data integrity isn’t a problem, then Meteor is right.
@rjdavid - how are you running transactions in your app?
I there’s a big misunderstanding. Meteor does not support transactions as in “it’s not a feature” — it never was. But it does support them as in “it’ll work if you’ll use them” — it always did.
It’s a feature of MongoDb, not Meteor. Somehow Meteor ignored this MongoDb feature since it was introduced (in 2019 I think).
I do understand that this was falling into the period where basically nothing much was done with Meteor but now that the community has taken over we should have added support for transactions or at least put it high up on the list.
BTW, the change to MongoDb version 5.x is only for M0, M2 and M5 clusters which are not suitable for production, so again this shows that Meteor is focusing rather on hobby projects and MVP’s than on production grade apps, as to my earlier comment.
Hi @a4xrbj1, I don’t understand where this comment is coming.
Meteor Cloud (Galaxy) is hosting thousands of Meteor apps. Most of them are big production-grade apps with thousands of customers/users (or even millions).
Why would we be interested in supporting only MVPs?
Specifically, about transactions, I have personally developed many big apps with Meteor not using MongoDB Transactions. There are many ways to keep data with integrity, MongoDB didn’t support transactions for many versions and big apps still used it.
I’m not saying we will never support Transactions, but I mean, transactions are possible today with Meteor. Still, if you are using something from rawCollection you know it’s a direct integration between your code and MongoDB.
Also, we are updating all the code related to MongoDB and Meteor to support MongoDB 5.0, and even in this case, you are saying that we don’t care about production-grade apps? Sorry, I don’t get it.
That’s right - it’s a feature of MongoDB. But Meteor relies heavily on oplog, and there is a support for oplog operations coming from transactions.
In other words, it is “ignored”, because there’s nothing to consider. It could be better, because right now it requires the rawCollection API, but it works. The same goes for aggregations, and yet nobody says they’re not supported.
I hope you are ready to enjoy your weekend.