Support defining the serializer and BSON representation for a property

[CristianBonilla]

Issue converted to Proposal by @Turnerj 2023-06-04

Proposal

Allow finer control of the serialization system for MongoDB through MongoFramework. Currently you can not control the BSON Representation (eg. C# string can't be represented as BSON ObjectId) however doing so allows greater compatibility in a number of scenarios.

This could be accomplished well with support for defining the serializer per-property in MongoFramework. With the appropriate extension methods during the builder process, you could then control the representation that would be used. This first-party support would then unlock the ability to do the same attribute-level control of serializer (and optionally representation).

Original Issue

It does not allow me to read the entities of a mongo database due to this problem.

[Turnerj]

It sounds like the existing data in the database isn't actually a string but a ObjectId. Try switching your entities type to ObjectId (its in the MongoDB.Bson namespace).

[CristianBonilla]

It sounds like the existing data in the database isn't actually a string but a ObjectId. Try switching your entities type to ObjectId (its in the MongoDB.Bson namespace).

@Turnerj it doesn't work like that either

[Turnerj]

Sorry, I mean change public string Id { get; set; } to public ObjectId Id { get; set; }

[CristianBonilla]

Turned out! but to deserialize to string no?

[Turnerj]

It is a little more complicated than that unfortunately. So when you use MongoFramework (or MongoDB's driver directly), if you use a string ID the actual data in MongoDB is literally a string property. ObjectId in MongoDB is actually a binary type.

So what we see happening here is that the DB has a binary ObjectId and C# was told to have a string, that was why it wasn't working.

This gets more unclear because, as far as I know, the name of the ID format that MongoDB uses is called "ObjectId".

It is probably possible to write some sort of converter system to allow string properties in the DB convert to ObjectId (and vice versa, like in your situation) however MongoFramework doesn't support this nor does the MongoDB Driver have anything built-in to do that.

[Turnerj]

Or maybe better explained another way, there are 3 types of IDs for the MongoDB Driver:

• string
• ObjectId
• Guid

Both string and Guid serialize to strings but ObjectId is serialized to a binary format. Your existing data in the DB is using the binary format method (it is ObjectId in the DB) which is why using string in C# didn't work.

[CristianBonilla]

I did a test using MongoDB.Driver and deserialization works effectively in string, so I don't know if the problem is directly in MongoFramework that does not allow deserialization

Result:

[Turnerj]

With your example now, you're telling the driver to specifically ignore the default representation for the serializer. There isn't an equivalent way to do so with MongoFramework currently. I've had a look into a few ways I could try and support BSON representation conversion but I'm not really a fan of what I've come up with currently.

I'd probably recommend using the appropriate C# type that matches the data in the database.

[CristianBonilla]

With your example now, you're telling the driver to specifically ignore the default representation for the serializer. There isn't an equivalent way to do so with MongoFramework currently. I've had a look into a few ways I could try and support BSON representation conversion but I'm not really a fan of what I've come up with currently.

I'd probably recommend using the appropriate C# type that matches the data in the database.

@Turnerj Do you think that in a future version of MongoFramework it will allow serialization like MongoDB.Driver allows?

[Turnerj]

Yes, mostly. Like I think being able to define what a particular property should be represented as is quite useful but I need to look at the bigger picture of how I'd integrate it with MongoFramework.

Right now the very high level design I'm thinking is with MongoFramework's internal mapping system, track the serializer used for a particular property - basically allow you to set IBsonSerializer. From there, I could just add some extension methods to my builder system to allow reconfiguring an existing serializer to change representation.

The big bit with this piece of work is that it makes MongoFramework responsible about what serializer is used for what property. By that I mean, MongoFramework will be determining the default serializer for each type rather than the driver by default. This is probably a good thing to do long term anyway (gives more flexibility in mapping) but given the wide variety of types that people could use, it becomes complicated ensuring backwards compatibility.

The end result then for consumers of MongoFramework would be both a similar attribute like the driver has to define the representation and also have first-party support in the fluent builder system.