[CSHARP-721] Insert fails to set SetIdMember interface members values Created: 09/Apr/13  Updated: 15/May/14  Resolved: 06/May/13

Status: Closed
Project: C# Driver
Component/s: None
Affects Version/s: 1.8.1
Fix Version/s: None

Type: Bug Priority: Blocker - P1
Reporter: Blake Niemyjski Assignee: Craig Wilson
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 8, MongoDB Latest


Issue Links:
Duplicate
is duplicated by CSHARP-743 ObjectId not getting returned Closed
Backwards Compatibility: Minor Change

 Description   

Using the same code as shown here: https://jira.mongodb.org/browse/CSHARP-708 I noticed that after updating to the 1.8.1 driver via NuGet that all my unit tests were failing. I tracked this down to the collection.Insert<T>(document) was failing to give an ObjectId value even though the representation was set to ObjectId for an interface member... Before and after the call to Insert the Id property value was null.

If you need a sample, I can try to put one together.



 Comments   
Comment by Blake Niemyjski [ 15/May/14 ]

Do you have any plans to change this back to the old behavior? Did you have a chance to look into this issue again?

Comment by Craig Wilson [ 06/May/13 ]

Let us know if you come across anything else while doing your tests. For now I'm going resolve this ticket.

Comment by Blake Niemyjski [ 06/May/13 ]

Hello,

It's all good. I went ahead and updated our solution to use the SetIdGenerator. I'm off to do lots of testing! Thanks again for taking the time to provide samples.

Comment by Craig Wilson [ 06/May/13 ]

In regards to the SetRepresentation, we've identified why the behavior is as it is. While it did behave the way you intended prior to 1.8, this was a side-effect of how mapping was previously done and nothing should have "automatically" happened after AutoMap was called. This is a somewhat irreversible change and will continue to be like this in the foreseeable future. I'd advise you to adopt one of the accepted ways of handling this above. i.e. write a custom convention to handle your specific scenarios. I've provided the code to get started with this above and copied here for convenience (https://gist.github.com/craiggwilson/5217295).

I apologize for the inconvenience this has caused. We do try hard to prevent breaking changes for minor releases and this was a scenario we didn't test for.

Comment by Blake Niemyjski [ 06/May/13 ]

Has there been any updates on this? We are starting to get blocked on this as various NuGet packages require 1.8.1

Comment by Blake Niemyjski [ 15/Apr/13 ]

Hello,

I believe that it should just work like it did in 1.7.x. If you set the representation, it should automatically insert a new ObjectId if one is not specified. I believe that By calling SetRepresentation, it should update the mapping correctly.

Comment by Craig Wilson [ 10/Apr/13 ]

Blake,
Thanks for the pull request. That is so helpful.

So, I'm actually unclear as to what the behavior here should be. I believe this may be a subtle change from the 1.7 branch, so my apologies for that. When we replaced the convention system in 1.8, the order certain things happened changed a little. We have a convention for noticing that your Id member is a string and it's representation is an ObjectId. You can see it registered here: https://github.com/mongodb/mongo-csharp-driver/blob/master/MongoDB.Bson/Serialization/Conventions/DefaultConventionPack.cs#L44.

The issue is that this all happens in AutoMap. In your pull request, you have set the ObjectId representation after all the conventions have run, so there is nothing to set the IdGenerator for this guy any longer. You can obviously do this manually like this...

//...
cm.SetIdMember(cm.GetMemberMap(c => c.Id).SetRepresentation(BsonType.ObjectId).SetIdGenerator(new StringObjectIdGenerator()));
//...

That obviously isn't of great comfort. A likely better alternative is for you to write a custom convention for this behavior so you don't need to do this all the time. For instance, in the following gist (https://gist.github.com/craiggwilson/5217295), you can create a convention that will recognize your particular Id pattern and do it without you needing to manually do anything with entities. (You could write another one that would take care of automatically setting IgnoreExtraElements to true as well ).

I'll need to confer with my colleagues about whether or not this is something we are going to fix or not. Could you let me know your thoughts on the situation and how important it is to you that we resolve this differently that the above options.

Craig

Comment by Blake Niemyjski [ 09/Apr/13 ]

Hey,

I created a pull request here: https://github.com/mongodb/mongo-csharp-driver/pull/155

Please note that I haven't verified the test as working in 1.7.1 but I believe it should. I borrowed from an existing unit test and updated it accordingly...

Comment by Craig Wilson [ 09/Apr/13 ]

Hi Blake,
Yes, some code would great. The code from CSHARP-708 is now in a unit test that is passing (https://github.com/mongodb/mongo-csharp-driver/blob/master/MongoDB.BsonUnitTests/Jira/CSharp708Tests.cs), so having some more information/other code would be very helpful.

Generated at Wed Feb 07 21:37:38 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.