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.

rstam · 2025-01-15T18:57:10Z

src/MongoDB.Bson/Serialization/BsonSerializationDomain.cs

+    internal class BsonSerializationDomain : IBsonSerializationDomainInternal, IDisposable
+    {
+        // private fields
+        private ReaderWriterLockSlim __configLock =


Use a single leading underscore for instance fields (double leading underscore for static fields).

rstam · 2025-01-15T18:58:36Z

src/MongoDB.Bson/Serialization/BsonSerializer.cs

-
-        private static bool __useNullIdChecker = false;
-        private static bool __useZeroIdChecker = false;
+        private static readonly IBsonSerializationDomainInternal _domain;


Use two leading underscores for static fields (single leading underscore for instance fields).

This field should probably be called __defaultDomain.

Yes, at the moment I'm not worrying too much about the code style, because I'm worried I could end up with a complete redesign in some days 😄

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.

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

src/MongoDB.Bson/Serialization/IBsonSerializationDomain.cs

+    /// <summary>
+    /// //TODO
+    /// </summary>
+    public interface IBsonCoreSerializer //TODO Don't like the name but have no better idea at the moment


I propose IBsonSerializationHelpers as the name of this interface.

rstam · 2025-01-15T20:04:38Z

src/MongoDB.Bson/Serialization/IBsonSerializationDomain.cs

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


I propose IBsonSerializationDomainConfigurator as the name of this interface.

"Core" in the name doesn't mean anything to me.

rstam · 2025-01-15T20:08:08Z

src/MongoDB.Bson/Serialization/IBsonSerializationDomain.cs

+        /// </summary>
+        /// <typeparam name="T">The type.</typeparam>
+        /// <returns>A serializer for type T.</returns>
+        IBsonSerializer<T> LookupSerializer<T>();


You may have put this method here thinking it was a read-only method but because we configure serialization on demand as needed calling this method might require creating and registering a new serializer, so this method can also modify the serialization domain.

Ouch, need to check that

rstam · 2025-01-15T20:09:32Z

src/MongoDB.Bson/Serialization/IBsonSerializationDomain.cs

+        /// //TODO
+        /// </summary>
+        /// <returns></returns>
+        IBsonCoreSerializer BuildCoreSerializer();


This method makes no sense to me and isn't used either.

This is not used at the moment, but I think this could be something that developers can use to create what now is called IBsonCoreSerializer. Once this method is called, the "domain/core serializer" is read only.
This is of course if I manage to separate completely the 3 interfaces

rstam · 2025-01-15T20:10:44Z

src/MongoDB.Bson/Serialization/IBsonSerializationDomain.cs

+        /// <summary>
+        /// Gets whether to use the NullIdChecker on reference Id types that don't have an IdGenerator registered is enabled.
+        /// </summary>
+        bool UseNullIdCheckerEnabled { get; }


This property and the next are never used and also seem to duplicate earlier methods in a different interface.

The idea here would be that this is part of the core serializer configuration, while the others are in the configurator, this is why these ones are read only

rstam · 2025-01-15T20:14:19Z

src/MongoDB.Bson/Serialization/IBsonSerializationDomain.cs

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


One hard part about trying to split up the single interface into smaller interface is that they sometimes end up with colliding names.

I would say this interface should maybe be called IBsonSerializationDomain but that's the name of the single bundled interface and I certainly don't want to change that one.

I propose IBsonSerializationDomainRegistry as the name for this interface.

I'm actually on the fence whether splitting the bundled interface into three is even worth it, given that we expect to massively redesign how serialization is configured in 4.0.

I'm also on the fence with it, but I think I could spend a little bit more time to see if this is something possible, or it would be too complicated for now.
It could also be a stepping stone for what we do in 4.0, otherwise we could end up making so many changes in the API and alienate users maybe?

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 8 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

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

rstam Jan 15, 2025

rstam Jan 15, 2025

papafe Jan 15, 2025

rstam Jan 15, 2025

papafe Jan 15, 2025

rstam Jan 15, 2025

rstam Jan 15, 2025

rstam Jan 15, 2025

papafe Jan 15, 2025

rstam Jan 15, 2025

papafe Jan 15, 2025 •

edited

Loading

rstam Jan 15, 2025

papafe Jan 15, 2025

rstam Jan 15, 2025

papafe Jan 15, 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

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

papafe Jan 15, 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

sanych-sun Jan 14, 2025 •

edited

Loading

papafe Jan 15, 2025 •

edited

Loading