I have been using Meteor for over a year now but I always feel like I am “doing it wrong” when it comes to error handling inserting to multiple collections with Meteor Methods. I can’t seem to find anything in the guide or on the forums that truly clears this up for me, but maybe that’s because I am misunderstanding it at some fundamental level? Apologies if I have missed something obvious.
Imagine a (presumably very common) scenario where the client calls a Meteor Method that must insert an entry into Collection A. If Collection A succeeds the next step is to insert a related entry into Collection B. If the Collection A insert fails, then the Collection B insert should NOT happen (easy enough). If the Collection B insert fails, then the new entry in Collection A is considered in a bad state and we need to do something about it. One option is to remove it manually I suppose. Is that the standard approach in Meteor? I suppose, if this scenario only happens once or twice in the app, it’s okay to just manually remove it, but ideally, we don’t want the overhead of doing inserts and removes to the database as part of the error handling (not to mention it just feels wrong - what if the remove fails for example?). What we really want is transactions where the db changes only happen at commit time at the end of the method, and any errors during the method will cause a rollback, right? This is just taken for granted where I come from in Java Enterprise Land, but from what I can figure out transactions aren’t supported by MongoDB, or at least not the version used by Meteor? I’m not really 100% sure, it’s all very confusing. Please correct me if I’m wrong about Mongo and transactions.
Any help/opinions/general feedback on how the above scenario is typically dealt with in Meteor would be greatly appreciated, thanks.