C# driver 1.10 and CSHARP-1042, obsolete MongoCommandException.CommandResult

[Roman Kuzmin]

https://jira.mongodb.org/browse/CSHARP-1042 says: MongoCommandException.CommandResult needs to be deprecated and new properties need to be added. But the new properties do not provide the same information as the old data. For example DocumentsAffected and UpdatedExisting are not available anymore for analysis.

Personally, I do not use these properties much, only my tests are affected and fail now. I can adjust the failing tests. But this information still seems to be potentially useful and yet missing.

Is this change final, i.e. DocumentsAffected and UpdatedExisting will not be exposed is some way?

[Craig Wilson]

The new property is called "Result" and is of type BsonDocument.

https://github.com/mongodb/mongo-csharp-driver/blob/v1.x/MongoDB.Driver/Exceptions/MongoCommandException.cs#L120

[Roman Kuzmin]

Yes but the new property Result does not contain DocumentsAffected and UpdatedExisting fields. Thus, this possibly useful information is lost (was useful at least for some tests). I will double check this soon (cannot right now).

[Craig Wilson]

No, it doesn't have those properties as part of the class (BsonDocument), but neither did CommandResult. There is nothing special about CommandResult that would have provided those properties in particular. It was just a wrapper around a BsonDocument which is now just being exposed as Result. Perhaps the code you are running would be helpful.

[Roman Kuzmin]

The code I use is the PowerShell module Mdbc ( https://github.com/nightroman/Mdbc ). Unless you know how to use it this is not that simple to provide the code to run and analyse. But I will try to explain what is going on.

True, the CommandResult itself does not have DocumentsAffected and UpdatedExisting. But the derived GetLastErrorResult does. In my test case a command throws an exception which property CommanResult type is WriteConcernResult which is derived from SafeModeResult and GetLastErrorResult. So it also has properties DocumentsAffected and UpdatedExisting. And the test can analyse them.

If I replace CommandResult with Result then there is no way to get these DocumentsAffected and UpdatedExisting.

My test adds documents with with already existing _id, so it calls Insert() on a MongoCollection.

[Craig Wilson]

So, you are catching a WriteConcernException which has a WriteConcernResult? I'm familiar with Mdbc, so a way for me to see more clearly what is going on is going to be necessary. I simply don't understand where the problem is.

Regardless of the actual situation, those properties are only wrappers around the response object.  You can see that here: https://github.com/mongodb/mongo-csharp-driver/blob/v1.x/MongoDB.Driver/CommandResults/GetLastErrorResult.cs#L46. For documents affected, get the "n" field from the Result BsonDocument. UpdatedExisting uses the "updatedExisting" property. I know it's not as elegant as a type-safe wrapper, but the server is changing the way it handles writes, moving away from getLastError, etc...

[Roman Kuzmin]

Here is the exception caught:

https://github.com/nightroman/Mdbc/blob/master/Src/Commands/AddDataCommand.cs#L69

Here it is written as the result if the result is requested

https://github.com/nightroman/Mdbc/blob/master/Src/Commands/AbstractWriteCommand.cs#L46

The test that triggers this scenario is the task WriteConcernResult:

https://github.com/nightroman/Mdbc/blob/master/Tests/Add-MdbcData.test.ps1#L110

It is run by Invoke-Build (https://github.com/nightroman/Invoke-Build) (similar to PSake):

PS> Invoke-Build WriteConcernResult Add-MdbcData.test.ps1

I understand that the old way internally has the same data and just wraps them by properties even if they do not exist in the underlying BsonDocument. So actually no info is lost with the new way, as I initially thought. This is good. But at least the old way makes it possible to return command results as the same strongly typed object in all cases, both success and failure. With the new way I have to return a command result on success and BsonDocument on failure. Thus, processing of a result will be slightly more difficult.

It is not a big deal for me. I will adjust my tests for using BsonDocument (Result) with no problems. I just wanted to be sure that this change in the driver is well weighted and all details are considered.