CSHARP-3985: Support multiple SerializerRegistries #1592

papafe · 2025-01-13T17:26:15Z

This reverts commit 5a93d57.

sanych-sun · 2025-01-14T03:19:26Z

src/MongoDB.Bson/Serialization/IBsonSerializationDomain.cs

+    /// <summary>
+    /// //TODO
+    /// </summary>
+    public interface IBsonSerializationDomain


Why do we need such super-interface? It has everything in it: configuration, resolving and even reading/writing. Is there any use case when one need all of this together? I would prefer to use 3 separate interfaces: IBsonSerializationBuilder (or similar, to contain everything related to configuration, registration) - when one done with configuration - can call Build method and get IBsonSerializerRegistry (+ we might want to make IBsonSerializerRegistry as readonly for lookup only) and finally there is IBsonSerializer (to contain Serialize-Deserialize methods). So we will separate all use-cases: for application bootstrap/configuration - one have to use IBsonSerializationBuilder, in run-time to resolve the serializer - IBsonSerializerRegistry should be used, and finally to read/write - we have IBsonSerializer itself.

BTW, having IBsonSerializationBuilder is very well aligned with idea of having MongoClientBuilder to create MongoClients. Serialization builder could be part of the bigger MongoClientBuilder.

I think the main problem here is that we're trying to move away from the static super-class that is BsonSerializer without creating a breaking change. At the moment IBsonSerialisationDomain is an interface with everything that BsonSerialiser does, so that we can create an instance class that we can inject where we need. At a later time (possibly we can break this ticket in multiple PRs) this would allow developers to define custom serialization configuration for a certain mongo client/database/collection.
And I agree that this interface does a lot, but so did BsonSerializer and unfortunately it's difficult to separate everything from each other without breaking what's already there, given that almost everything is in the public API and we can't change the behaviour before a new major. For example, one of the issue we have is that the code to work with discriminators is not part of IBsonSerializerRegistry, but it's all over the place.
I feel that moving away from a static class would already be a positive change for the future, and that changing the way we do serialisation is definitely something we should do, but that would require changing the public API and a new major version.
What do you think?
Also @rstam tagging you here so you can follow the conversation 😄

I do understand that we are limited by not allowing to have a breaking changes, but if we decide to introduce a new interface(s), let's make them useful for initiatives that will follow soon. Let's discuss pros and cons of each idea with whole team.

src/MongoDB.Bson/Serialization/BsonSerializationDomain.cs

src/MongoDB.Bson/Serialization/BsonSerializer.cs

rstam · 2025-01-15T20:03:11Z

src/MongoDB.Bson/Serialization/IBsonSerializationDomain.cs

+        /// <summary>
+        /// //TODO
+        /// </summary>
+        IBsonCoreSerializerConfiguration SerializationConfiguration { get; }


I think this property doesn't belong in this interface.

My idea would be that the IBsonCoreSerializer interface would contain everything that can be used to do the serialization and this also includes the configuration necessary for that.

src/MongoDB.Bson/Serialization/IBsonSerializationDomain.cs

papafe · 2025-01-30T20:10:35Z

This is still a super quick and dirty proof of concept, just to verify we can actually create a custom domain and move it along down the call stack. Of course this broke down several things, and works only in certain cases, but it's a starting point.
The main idea here is:

The serialization domain (IBsonSerializationDomain) can be setup at the client/database/collection level
The serialization domain is also added to the serialization context (BsonSerializationContext/BsonDeserializationContext). This way it is passed down wherever it is needed
In order to pass the serialization domain between the collection level and the BsonSerializationContext, the serialization domain is passed down in the MessageEncoderSettings,
From MessageEncoderSettings, the domain is then added to the BsonBinaryWriterSettings in the MessageBinaryEncoderBase.
Finally, the writer settings are read in the serialization context constructor.

(This works similar for `BsonSerializationContext)

I'm not trying to say that this is the perfect way, but I just tried to come up with the "most direct" way to go from the collection to the serialization contexts, so it's mostly a proof of concept.

Also, I still did not touch the conventions, the discriminators and the class maps, that are also statics and need to be part of the serialization domain.

rstam

I didn't review every single file. I tried to pick the most relevant ones.

Overall this looks like the right direction.

But... it's going to be a pain to finish and to review.

rstam · 2025-02-07T00:03:05Z

src/MongoDB.Bson/IO/BsonReaderSettings.cs

+        /// <summary>
+        /// //TODO
+        /// </summary>
+        public IBsonSerializationDomain SerializationDomain


I can't find anywhere this property is used.

It's used in the constructor of the BsonDeserializationContext.

rstam · 2025-02-07T00:03:48Z

src/MongoDB.Bson/IO/BsonWriterSettings.cs

+        /// <summary>
+        /// //TODO
+        /// </summary>
+        public IBsonSerializationDomain SerializationDomain


I can't find anywhere this property is used.

It's used in the constructor of the BsonSerializationContext

rstam · 2025-02-07T00:06:11Z

src/MongoDB.Bson/IO/IBsonReader.cs

@@ -62,7 +62,7 @@ public interface IBsonReader : IDisposable
        /// <summary>
        /// Pops the settings.
        /// </summary>
-        void PopSettings();
+        void PopSettings();  //TODO Why do we have push and pop methods? They are not used


I'm surprised they are not used.

The matching methods in IBsonWriter are used.

rstam · 2025-02-07T00:08:59Z

src/MongoDB.Bson/Serialization/Conventions/AttributeConventionPack.cs

-            public void Apply(BsonMemberMap memberMap)
+            public void Apply(BsonMemberMap memberMap) => Apply(memberMap, BsonSerializer.DefaultDomain);
+
+            public void Apply(BsonMemberMap memberMap, IBsonSerializationDomain domain)


new domain parameter is not used?

rstam · 2025-02-07T00:09:11Z

src/MongoDB.Bson/Serialization/Conventions/AttributeConventionPack.cs

-            public void PostProcess(BsonClassMap classMap)
+            public void PostProcess(BsonClassMap classMap) => PostProcess(classMap, BsonSerializer.DefaultDomain);
+
+            public void PostProcess(BsonClassMap classMap, IBsonSerializationDomain domain)


new domain parameter is not used?

rstam · 2025-02-07T00:17:49Z

src/MongoDB.Bson/Serialization/BsonClassMap.cs

        {
-            BsonSerializer.ConfigLock.EnterReadLock();
+            var configLock = (context.SerializationDomain as IBsonSerializationDomainInternal)!.ConfigLock;  //TODO This is ugly


You could create a FreezeContext method to do the ugly part:

var configLock = context.GetConfigLock();

We could! To be honest, I'm not sure how we want to deal with Freeze. It's a very special method, as it calls static methods, and uses static variables internally.
I tried to isolate them by creating the FreezeContext, but it's still not 100% correct and I'm not sure how we can completely separate it from the static part.

rstam · 2025-02-07T00:22:44Z

src/MongoDB.Bson/Serialization/BsonSerializationContext.cs

+        /// <summary>
+        /// //TODO
+        /// </summary>
+        public IBsonSerializationDomain Domain => _domain;


Should probably standardize on Domain or SerializationDomain.

SerializationDomain is more accurate, but longer...

I agree, at the moment it's a little bit here and there. I think serialization domain is a better name, even if longer.

rstam · 2025-02-07T01:42:03Z

src/MongoDB.Bson/Serialization/IBsonSerializationDomain.cs

+    /// <summary>
+    /// //TODO
+    /// </summary>
+    public interface IBsonSerializationDomain


IBsonSerializationDomain is a good name... but maybe you want to reserve it for 4.0?

If all we are doing is going from static to instance registries maybe a name like IBsonSerializationRegistries would work.

To be honest I think we need to discuss how much of a change we are willing to do for this work. For example, we can't implement this PR without adding the serialization domain to some public interfaces, and this would constitute a binary breaking change.
Also I think that IBsonSerializationRegistries is a little confusing, since it's not only serialization registries.

papafe added 12 commits January 8, 2025 11:20

First test

5a93d57

Revert "First test"

bc33071

This reverts commit 5a93d57.

Added manager

5e94e62

Delegating all the methods to the BsonSerializationManager

a317994

Added interface

0e2f7b9

Small fix

a051d18

Rename

bb60887

Added internal interface

56a9b7e

Improvements

3f634d5

Initial use of domain

550eb97

Fix

d2e1746

Added comments

8b14426

sanych-sun reviewed Jan 14, 2025

View reviewed changes

rstam self-requested a review January 14, 2025 17:11

papafe added 4 commits January 15, 2025 11:34

Test with multiple interfaces

3dadb07

Improved interfaces

cf05d41

Fix to interface

35f461a

Small renaming

7c2beb3

rstam requested changes Jan 15, 2025

View reviewed changes

papafe added 11 commits January 27, 2025 09:48

Added comments

3ad811e

Finished comments in the Bson lib

0ae768c

Corrected conventions

01330fd

Correction

7bec37f

Corrected convention tests

bb395b0

Removed multiple interfaces plus more fixes

d7756c6

More improvements

70f351b

Small fixes

cc40c72

Small fixes

04d45fa

improvements

8305dc1

Small fix

402a889

papafe added 3 commits January 30, 2025 17:24

Various fixes

6d2faf9

First test passing

5ac0c06

Small fixes

7628f31

Some saving

3f5a047

papafe requested review from rstam and sanych-sun January 31, 2025 11:14

papafe added 12 commits February 3, 2025 09:56

Naming correction

9ccfe7a

Added test and removed comment

d3973e1

Improved tests

a587d6d

Improved deserialization to work as serialization

856cfb8

Trying to fix class map

2cc6a8d

Fixed class

5742541

Various corrections

d6d9ddc

Moved class map to another file

3b27b43

Removed comments

98682bb

Passing domain in serializer registry

dc33112

Small improvements

a45b027

Small corrections

3f9c37c

rstam requested changes Feb 7, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CSHARP-3985: Support multiple SerializerRegistries #1592

CSHARP-3985: Support multiple SerializerRegistries #1592

papafe commented Jan 13, 2025

sanych-sun Jan 14, 2025 •

edited

Loading

sanych-sun Jan 14, 2025

papafe Jan 14, 2025

sanych-sun Jan 14, 2025

rstam Jan 15, 2025

papafe Jan 15, 2025

papafe commented Jan 30, 2025 •

edited

Loading

rstam left a comment

rstam Feb 7, 2025

papafe Feb 7, 2025

rstam Feb 7, 2025

papafe Feb 7, 2025

rstam Feb 7, 2025

rstam Feb 7, 2025

rstam Feb 7, 2025

rstam Feb 7, 2025

papafe Feb 7, 2025

rstam Feb 7, 2025

papafe Feb 7, 2025

rstam Feb 7, 2025

papafe Feb 7, 2025

CSHARP-3985: Support multiple SerializerRegistries #1592

Are you sure you want to change the base?

CSHARP-3985: Support multiple SerializerRegistries #1592

Conversation

papafe commented Jan 13, 2025

sanych-sun Jan 14, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

papafe commented Jan 30, 2025 • edited Loading

rstam left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sanych-sun Jan 14, 2025 •

edited

Loading

papafe commented Jan 30, 2025 •

edited

Loading