-
Notifications
You must be signed in to change notification settings - Fork 1.3k
CSHARP-3494: Fix discriminator for generic types #1685
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
This is still a draft as we need to discuss if this is the kind of solution we want. |
|
||
namespace MongoDB.Driver.Tests.Jira | ||
{ | ||
public class CSharp3494Tests : Linq3IntegrationTest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can decide to move these tests somewhere else if it makes more sense. Also this test does not need to derive from Linq3IntegrationTest
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If these tests don't use the driver they should live in the MongoDB.Bson.Tests
project instead of here.
But you may want to make integration tests also, where we write a document to the database and prove that we can read it back.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've moved these tests to the DiscriminatorTests
, as it seems we're trying to avoid to have ticket-specific test classes and integrate them more with our test suite. I have also changed their names to be in line with the other tests in the file.
I'm not sure what could be an appropriate location for some integration tests though. Do you have any suggestions?
@@ -1057,7 +1057,7 @@ public void Reset() | |||
_creatorMaps.Clear(); | |||
_creator = null; | |||
_declaredMemberMaps = new List<BsonMemberMap>(); | |||
_discriminator = _classType.Name; | |||
_discriminator = BsonUtils.GetFriendlyTypeName(_classType); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might fix it for BsonClassMap
based serializers.
But shouldn't this be fixed more generally somehow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We had an offline discussion, and we decided it would make sense to keep this fix limited to BsonClassMap
based serializers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need a new JIRA ticket for supporting discriminators for generic types when NOT using BsonClassMap
?
|
||
namespace MongoDB.Driver.Tests.Jira | ||
{ | ||
public class CSharp3494Tests : Linq3IntegrationTest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If these tests don't use the driver they should live in the MongoDB.Bson.Tests
project instead of here.
But you may want to make integration tests also, where we write a document to the database and prove that we can read it back.
{ | ||
public class CSharp3494Tests : Linq3IntegrationTest | ||
{ | ||
abstract class BaseDocument; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Normally we put all the classes after the test methods.
In this file they are mixed in an unusual order, switching back and forth between test methods and class declarations.
rehydrated.Should().BeOfType<DerivedDocument2<int>>(); | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should test generic types with more than one type parameter like Dictionary<string, int>
.
And see if you can come up with a test with nested generic types, maybe something like IEnumerable<KeyValuePair<string, int>>
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
{ | ||
var document = new DerivedDocument<int> { Id = 1, Value = 42 }; | ||
var serialized = document.ToJson(typeof(BaseDocument)); | ||
serialized.Should().Be("""{ "_t" : "DerivedDocument<Int32>", "_id" : 1, "Value" : 42 }"""); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought the _id
was always supposed to be first.
But maybe we only do that during serialization (and only in BsonClassMapSerializer
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I investigated a little... It seems that for BsonClassMapSerializer
the _id
field gets serialized first only if BsonSerializationArgs.SerializeIdFirst
is true, but only set it to true on tests.
Is this something we should create a ticket for?
@@ -1057,7 +1057,7 @@ public void Reset() | |||
_creatorMaps.Clear(); | |||
_creator = null; | |||
_declaredMemberMaps = new List<BsonMemberMap>(); | |||
_discriminator = _classType.Name; | |||
_discriminator = BsonUtils.GetFriendlyTypeName(_classType); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need a new JIRA ticket for supporting discriminators for generic types when NOT using BsonClassMap
?
} | ||
|
||
//The deserialization tests for generic types needs to use a different set of classes than the serialization ones, | ||
//otherwise the discriminators could have been already registered, depending on the order of the tests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this dependent on the order of the tests?
Configuration of classes/discriminators should work no matter what order the tests are run in.
No description provided.