A wrapper of rawCollection() to bring back deprecated behaviors + deprecation warning on use.
On our projects, the migration plan for this new version is not to join the testing since it requires checking the hundreds of instances of rawCollection usage. We will catalogue the functions used so we can decide if it is just mostly a change in function name or do we have to be concerned on the returned values e.g. using deprecated keys from results.
Question related to driver migration: can we do the changes while in Meteor 2.5 (MongoDB driver 3.x)? Ideally we can batch the migration into phases:
P.S. we just migrated from bootstrap 4 to 5, and currently in the middle of react-router 5 to 6. The experience with react-router 5 to 6 is ideal for us because there is a migration plan that allows us to stay in version 5 while slowly changing our code to support version 6. There are still work to be done once we migrated to v6 but a large part of the migration has been done, tested, fixed, and even shipped to production
I fail to see what would be the benefit of Meteor writing its own wrapper around MongoDBâs transactions. Right now in any Meteor project you absolutely can use transactions - using the official Node driver, like Mongo devs have envisioned it, via the convenience of rawCollection. Relying on the official Node driver gives you the best chance of being future proof and it ensures the least amount of bugs since this is the standard way for Node, very widely used and tested by the masses.
Writing some sort of a wrapper around transactions specifically for Meteor would not provide any benefits in terms of reliability or testing, but it would create an extra layer of complexity that needs to be maintained and tested. Thatâs a harsh price to pay just for some syntaxtic sugar (i.e. avoiding rawCollection).
The only reason it at all makes sense for Meteor to maintain its own layer of code on top of MongoDBâs official driver is that pub/sub makes it necessary to maintain minimongo (and server side perhaps the use of Fibers as well, which are on their way out anyway). Keeping that complexity to a minimal level is the best way to ensure reliability and maintainability of Meteor code and less pain in between updates to MongoDBâs drivers.
If your goal is to write reliable enterprise level software, then the current approach is exactly the best one - keep Meteor as simple as possible and to the maximum extent make use of the standard widely used and tested building blocks. Just like Meteor is doing with transactions.
I Agreed with @vooteles about handling mongodbâs transactions.
One feature I think Meteor should bring in is MongoDB Change Streams
. Meteor pub/sub currently relies on tailing oplog file. Itâs not good for big app with multiple instances of meteor (node). If we can use Change Streams feature instead, it will be masive improved in performance.
Thanks for your view which I agree to.
I still think that more support for Meteor users in using MongoDb transactions in their apps is needed. A quick search on the Meteor guide brings no result if someone searches for transactions.
Not even an article which gives instructions on how to use the rawCollection API. Or code examples how to set up a mongoSession, how commit transactions and how to handle rollbacks in case of errors.
On the other hand we do find articles on Oplog. So why is one explained and the other not?
I second that excellent point by RJ
@rjdavid @a4xrbj1 Currently I am using code similar to
const insertWriteOpResultObjectToInsertManyResult = ({
result: {ok},
insertedCount,
insertedIds,
}) => ({
acknowledged: Boolean(ok),
insertedCount,
insertedIds,
});
to achieve the opposite: make the 3.x driver behave like a 4.x. I am not sure the logic is correct but at least it gives the correct shape to the output.
This translation step is part of a bigger abstraction that should allow me to update painlessly to MongoDB 5, that is, by simply dropping the (centralized) translation calls.
Note that this is a new component of an app so I had the luxury to plan ahead, knowing 4.x drivers had a different interface. I did not have to rewrite any code.
Yep. Maybe the MongoDB 5 upgrade should yield a major bump of Meteor?
@a4xrbj1 I wrote a bunch of wrappers. The main one provides an âisomorphicâ interface on top of Meteorâs isomorphic collections interface. Itâs a bit heavyweight, but it is generic, and it works. I can declare transactions that are executed as such on the server and that can be simulated on the client without change. Not sure though how relevant, since large transactions are difficult to simulate on the client without tweaks, and small transactions are not supposed to be used in MongoDB. I can just say it works, and I am more comfortable relying on generic MongoDB transactions guarantees than to design my own âtransactionlessâ adhoc ACID system.
That sounds interesting @aureooms. We use a few rawCollection methods and have the odd wrapper. Not on transactions though. If youâre happy to share it would interesting to see how you handled it.
Hi, @rjdavid @aureooms @a4xrbj1, what changes are required to make transactions work in 4.x driver coming from 3.x?
I didnât find any mention to transaction changes here and here.
But we also didnât find mention for many things that were changed and affected Meteor, so maybe there are changes to transactions that are undocumented as well.
2.6 Migration Guide updated.
In this version, the content is pretty much the same but weâve made more clear the impact on rawColleciton as suggested here, also the changelog now highlights more the Driver change.
We donât use transactions in our Meteor projects.
Hm, got it.
What is your biggest concern with rawCollection usage? Do you already know something that is going to break?
Iâm asking that because we would like to provide examples or PRs (in case of packages) as we did for aggregate here. So others could benefit from this knowledge to have a better time upgrading.
Of course, we can complement this document later as well.
I just looked at the sample code provided here (changes in meteor provided above). I know that function name changes and the return keys of one of the function will require changes in our code.
But I still do not have visibility of how big the work really is until we make the actual function audit + reading the migration doc for 3.x to 4.x. it was just not a good timing for us to do this now as we are in the middle of react-router migration.
And yes, examples of these changes will help a lot. Even just giving us the heads up that we need to take a look at the aggregation queries like in this example
Weâve published now Meteor 2.6-rc.0
It includes Cordova changes as well, to support the latest Launch Screens for iOS.
@filipenevola I use transactions, but the changes required are not transaction specific. Where I am affected is that all return values of the Create Read Update Delete API methods have changed. This affects pretty much every operation through the MongoDB driver, including transactions. I have not noticed anything specific to transactions that would change. I know the recommended way to run a transaction is now withTransaction instead of startTransaction but I do not know if the startTransaction API has been deprecated, I doubt it. The session object is passed as usual without change. Maybe someone else has experience with other parts of the API that are only accessible through .rawCollection(), like aggregation queries.
I am going to do a first attempt at upgrading soon with a project. I have simulated an upgrade before introducing heavy usage of .rawCollection() through transactions and everything seems to work without problem. Will see how much work is needed with the more recent codebase.
Well essentially you define an interface that can do all CRUD operations, or even more for convenience, with a common API. Then you can have an implementation that stores a session object and delegates all calls to the MongoDB driver, an implementation that delegates all calls to Meteor collection methods, etc. Then, depending on who is executing the code (client/server), you choose which implementation of the interface you use. See a rough draft here patients/TransactionDriver.ts at main ¡ infoderm/patients ¡ GitHub