CSHARP-5442: Fixed use of serializer by Atlas Search operators by papafe · Pull Request #1583 · mongodb/mongo-csharp-driver

papafe · 2024-12-31T14:56:55Z

papafe · 2024-12-31T15:45:03Z

@BorisDog I've added you as a reviewer since it seems you were the one that worked on search, mostly. This is still a work in progress, I've broke some things in the process.
A couple of notes:

Probably we need to change the in and range search definitions as well to use the correct serializers.
This is effectively a behaviour breaking change, so we need to decide if we want include it in next version or wait for next major

papafe · 2025-01-02T11:20:23Z

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

+
+                var renderedField = _arrayField.Render(args);
+
+                var serializer =


Incredibly ugly, but was just testing if it worked

@rstam this is what I was referring to.
Do you think it would be worth adding a new property to RenderArgs so that we can get directly the serializer we need (similar to RenderForElemMatch for instance)?

I think this is on the right track but can use a little tweaking to how the right serializer is found and to reduce duplication between how scalar and array fields are handled.

Something like this:

private protected override BsonDocument RenderArguments(RenderArgs<TDocument> args) { IBsonSerializer<TValue> valueSerializer; if (_field != null) { var renderedField = _field.Render(args); valueSerializer = renderedField.FieldSerializer; } else { var renderedArrayField = _arrayField.Render(args); valueSerializer = (IBsonSerializer<TValue>)ArraySerializerHelper.GetItemSerializer(renderedArrayField.FieldSerializer); } var document = new BsonDocument(); using var bsonWriter = new BsonDocumentWriter(document); var context = BsonSerializationContext.CreateRoot(bsonWriter); bsonWriter.WriteStartDocument(); bsonWriter.WriteName("value"); valueSerializer.Serialize(context, _value); bsonWriter.WriteEndDocument(); return document; }

Perfect, this solves my doubts. That makes sense, I was mostly focusing on how to get the correct serializer before trying to refactor.

Regarding IBsonArraySerializer, the majority of times when we implement that interface we also implement IChildSerializerConfigurable, and that makes sense. It also seems that for this use case the result we'd get would be the same, so what would you think about using IChildSerializerConfigurable instead?
To be honest this is more of a generic question, I'm curious about if there's any preference on using one over the other, of course considering that TryGetItemSerializationInfo can potentially return more info (not in this case though).

IBsonArraySerializer and IChildSerializerConfigurable are orthogonal. We can't just implement IChildSerializerConfigurable instead of IBsonArraySerializer.

In this case we must implement IBsonArraySerializer.

It is true that in general whenever implementing IBsonArraySerializer we would likely also want to implement IChildSerializerConfigurable. However, that applies mostly to public serializers that a user might want to configure. This is an internal serializer, so I think implementing IBsonArraySerializer is sufficient.

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

rstam · 2025-01-03T20:36:55Z

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

+        public EqualsSearchDefinition(FieldDefinition<TDocument, TField> path, TField value, SearchScoreDefinition<TDocument> score)
+            : base(OperatorType.Equals, new SingleSearchPathDefinition<TDocument>(path), score)
+        {
+            ValidateType();


I question whether we need to have ValidateType at all. Looks to me like this was just a client-side limitation related to what .NET types ToBsonValue knew how to convert to BSON, but now that we are using the proper serializer this limitation should no longer exist.

I checked with Boris and he confirmed that it is a server limitation which types are supported.

But even so, we probably shouldn't be checking this client side. We should just send the value to the server and let it return an error if it doesn't support the data type.

That way our driver will work well with all supported versions of the server, which might have different limitations. And if future server versions support new value types we won't have to make any changes.

I also like this idea. I tried to keep it consistent with what was there before, but I agree that moving this check server side would allow us to be more free in what we do and don't support over time.
I need to remember to do the same with the other operators too.

rstam · 2025-01-03T20:38:34Z

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

+
+                var renderedField = _arrayField.Render(args);
+
+                var serializer =


I think this is on the right track but can use a little tweaking to how the right serializer is found and to reduce duplication between how scalar and array fields are handled.

Something like this:

private protected override BsonDocument RenderArguments(RenderArgs<TDocument> args) { IBsonSerializer<TValue> valueSerializer; if (_field != null) { var renderedField = _field.Render(args); valueSerializer = renderedField.FieldSerializer; } else { var renderedArrayField = _arrayField.Render(args); valueSerializer = (IBsonSerializer<TValue>)ArraySerializerHelper.GetItemSerializer(renderedArrayField.FieldSerializer); } var document = new BsonDocument(); using var bsonWriter = new BsonDocumentWriter(document); var context = BsonSerializationContext.CreateRoot(bsonWriter); bsonWriter.WriteStartDocument(); bsonWriter.WriteName("value"); valueSerializer.Serialize(context, _value); bsonWriter.WriteEndDocument(); return document; }

rstam · 2025-01-03T20:40:16Z

src/MongoDB.Driver/FieldValueSerializerHelper.cs

            private readonly IBsonSerializer<TItem> _itemSerializer;

+            public IBsonSerializer<TItem> ItemSerializer => _itemSerializer;
+


Instead of adding this new public property have the class implement IBsonArraySerializer and implement the TryGetItemSerializationIinfo method:

public bool TryGetItemSerializationInfo(out BsonSerializationInfo serialization { serializationInfo = new(elementName: null, _itemSerializer, typeof(TItem)); return true; }

All serializers for array-like values should implement IBsonArraySerializer. I don't know why this class did not already implement it.

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

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

+                var renderedField = _arrayField.Render(args);
+
+                var serializer =
+                    (renderedField.ValueSerializer as FieldValueSerializerHelper.IEnumerableSerializer<TField>)


Instead of trying to cast to the very specific class FieldValueSerializerHelper.IEnumerableSerializer<TField> use the more general from (used everywhere else) to get the item serializer from an array-like serializer:

valueSerializer = (IBsonSerializer<TValue>)ArraySerializerHelper.GetItemSerializer(renderedArrayField.FieldSerializer);

This is why FieldValueSerializerHelper.IEnumerableSerializer<TItem> should implement IBsonArraySerializer (as all array-like serializers should). Not sure why it didn't already...

rstam · 2025-01-03T22:23:20Z

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

+        public EqualsSearchDefinition(FieldDefinition<TDocument, TField> path, TField value, SearchScoreDefinition<TDocument> score)
+            : base(OperatorType.Equals, new SingleSearchPathDefinition<TDocument>(path), score)
+        {
+            ValidateType();


I checked with Boris and he confirmed that it is a server limitation which types are supported.

But even so, we probably shouldn't be checking this client side. We should just send the value to the server and let it return an error if it doesn't support the data type.

That way our driver will work well with all supported versions of the server, which might have different limitations. And if future server versions support new value types we won't have to make any changes.

tests/MongoDB.Driver.Tests/Search/SearchDefinitionBuilderTests.cs

src/MongoDB.Driver/FieldValueSerializerHelper.cs

tests/MongoDB.Driver.Tests/Search/SearchDefinitionBuilderTests.cs

src/MongoDB.Driver/Search/SearchDefinition.cs

src/MongoDB.Driver/Search/SearchDefinitionBuilder.cs

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

src/MongoDB.Driver/FieldValueSerializerHelper.cs

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

tests/MongoDB.Driver.Tests/Search/SearchDefinitionBuilderTests.cs

rstam

I'm not too familiar with the Search API but as far as I can tell this looks OK.

You should get one more LGTM before merging to main though.

papafe · 2025-01-14T10:30:54Z

I'm not too familiar with the Search API but as far as I can tell this looks OK.

You should get one more LGTM before merging to main though.

@sanych-sun can you take a look too?

papafe · 2025-01-28T19:52:10Z

@BorisDog another thing to consider is that this is a behaviour breaking change, so we need to consider if we want to merge this now or wait. I think it could also be seen as a bug fix to be honest, but we should take a decision.
The difference is that now the correct registered serializers are used to serialize the values for the equals, in and range operators, while before default conversions were used, ignoring the registered serializers.

src/MongoDB.Driver/FieldValueSerializerHelper.cs

src/MongoDB.Driver/Search/SearchDefinition.cs

BorisDog · 2025-02-04T21:07:04Z

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

-            value switch
+        private protected override BsonDocument RenderArguments(RenderArgs<TDocument> args)
+        {
+            var searchPathDefinition = (SingleSearchPathDefinition<TDocument>)_path;


It's a bit inefficient that we need to render the path twice.
Also it would be good to extract this to a single helper method.

What do you and @rstam think about having new internal Render method in SearchPathDefinition, something like

(BsonValue, RenderedFieldDefinition) Render(...)

And passing field serializer in OperatorSearchDefinition.RenderArguments() ?

I see your point. I also think it's a little complicated to extract a method like that to SearchPathDefinition, since (BsonValue, RenderedFieldDefinition) Render(...) would make sense for a SingleSearchPathDefinition, but not for MultiSearchPathDefinition or WildcardSearchPathDefinition.
The issue here is that operators support various degrees of SearchPathDefinition. I'm trying to think of a more general solution that does not make breaking changes in the public API, but so far it all feels kinda clunky.

Yeah I meant that the returned RenderedFieldDefinition would be null in some cases. I agree that it's not the greatest design, but I don't have any better suggestion as of now. I does have the upside of not rendering the path twice.
As long as all the API changes are internal, we can evolve them in the future if we come up with a better idea (the new suggested Render method should be internal).

In 60c1d57, I've added a fix to avoid rendering the path twice. It's not super nice, and I'm not sure it's worth it given that probably the network call of the atlas search would be much greater than the time needed to render the path twice.

I think that if we want to have special cases depending on the path we could also specialize OperatorSearchDefinition.RenderArguments and produce a different method for each path type, for example OperatorSearchDefinition.RenderArgumentsForSingleSearchPath where we can pass additional arguments. This would require quite some changes, but could also allow to control which kind of path can be used with certain kinds of operators.

papafe · 2025-02-06T20:26:20Z

@BorisDog I've done some corrections following your suggestions, and it looks much better than before, thank you 😄
I'm a little bit unsure about the names though, they feel a little redundant

BorisDog · 2025-02-07T00:14:33Z

src/MongoDB.Driver/Search/SearchPathDefinition.cs

+
+        internal virtual (BsonValue, IBsonSerializer) RenderAndGetFieldSerializer(RenderArgs<TDocument> args) => (Render(args), null);
+
+        internal (string renderedPath, IBsonSerializer fieldSerializer) RenderFieldWithSerializer(FieldDefinition<TDocument> fieldDefinition, RenderArgs<TDocument> args)


RenderFieldWithSerializer might be sound like "Render the field with provided serializer"
Would RenderFieldAndGetFieldSerializer be more accurate?

Yes, I think it makes sense

BorisDog · 2025-02-07T03:27:20Z

tests/MongoDB.Driver.Tests/Search/SearchDefinitionBuilderTests.cs

-            AssertRendered(
-                subject.Equals("x", value),
-                $"{{ equals: {{ path: 'x', value: {valueRendered} }} }}");
+            //There is no property called "x" where to pick up a properly configured GuidSerializer for the tests


I'm not sure I fully understand this exclusion. Is the default guid serializer different from the one used by serialization?

I think I need to improve the comment, I agree it's not super clear.
The issue here is that when we use a string path, we're going to get the default serializer for the value, so GuidSerializer. In v3.0 we decided to have GuidRepresentation.Unspecified as the default Guid representation, and this will throw an exception when trying to serialize/deserialize. Normally a user would go over this by registering a default GuidSerializer with the proper representation (BsonSerializer.Register...(GuidSerializer)), but we can't do it because the registered serializers are global and this would be a problem for all the other tests.

For the typed path on line 305 it's not an issue since we get the default field serializer from the class, and the Guid property has the BsonGuidRepresentation attribute on it.

This is more of a testing issue and should be solved when we can pass down the serialization domain 😁

BorisDog · 2025-02-07T03:31:27Z

tests/MongoDB.Driver.Tests/Search/SearchDefinitionBuilderTests.cs

            new object[] { (double)1, "1", Exp(p => p.Double), nameof(Person.Double) },
            new object[] { DateTime.MinValue, "ISODate(\"0001-01-01T00:00:00Z\")", Exp(p => p.Birthday), "dob" },
-            new object[] { DateTimeOffset.MaxValue, "ISODate(\"9999-12-31T23:59:59.999Z\")", Exp(p => p.DateTimeOffset), nameof(Person.DateTimeOffset) },
+            new object[] { DateTimeOffset.MaxValue, """{ "DateTime" : { "$date" : "9999-12-31T23:59:59.999Z" }, "Ticks" : 3155378975999999999, "Offset" : 0 }""", Exp(p => p.DateTimeOffset), nameof(Person.DateTimeOffset) },


So does this mean that we are changing the defaults also for non typed queries (SearchDefinitionBuilder<BsonDocument>)?

If so, that might be considered a bug and a breaking change.

Yes it will change also for non typed queries. They would need to convert the DateTime themselves if they want to keep the same behaviour.

It's probably a breaking change, but I'm not sure this can be considered a bug. If you're working directly with Bson documents then I assume that you would like to control how to the values are serialized in any case.

papafe · 2025-02-07T07:02:01Z

@BorisDog, as an additional note. I've tried making an untyped query (using BsonDocument) and passing a DateTime value for the Equal operator. No error returned but zero results as expected.

src/MongoDB.Driver/Search/SearchDefinition.cs

rstam · 2025-04-09T18:37:57Z

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

    }

-    internal sealed class EqualsSearchDefinition<TDocument, TField> : OperatorSearchDefinition<TDocument>
+    internal sealed class EqualsSearchDefinition<TDocument, TValue> : OperatorSearchDefinition<TDocument>


I know it was my suggestion to change TField to TValue, but I think that was a mistake.

This actually should be the type of the field, and the value of course should match the type of the field.

Note that all other classes in this file (that weren't modified) also use TField.

Ignore the fact that for array fields sometimes the inferred TField value is "wrong" (for example TField might be inferred to be int when the actual TField is int[]). That's just a pre-existing flaw in our API design.

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

rstam · 2025-04-09T18:41:35Z

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

    }

-    internal sealed class InSearchDefinition<TDocument, TField> : OperatorSearchDefinition<TDocument>
+    internal sealed class InSearchDefinition<TDocument, TValue> : OperatorSearchDefinition<TDocument>


As commented above keep TField and do not rename it.

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

rstam · 2025-04-09T18:44:30Z

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

    }

-    internal sealed class RangeSearchDefinition<TDocument, TField> : OperatorSearchDefinition<TDocument>
+    internal sealed class RangeSearchDefinition<TDocument, TValue> : OperatorSearchDefinition<TDocument>


As mentioned above keep TField.

rstam · 2025-04-09T18:47:59Z

src/MongoDB.Driver/Search/SearchDefinition.cs

+        /// <exception cref="InvalidOperationException">Thrown if <paramref name="searchDefinition"/> is not of a valid type/>.</exception>
+        public static SearchDefinition<TDocument> WithConfiguredSerialization<TDocument>(this SearchDefinition<TDocument> searchDefinition, bool useDefaultSerialization)
+        {
+            if (searchDefinition is not OperatorSearchDefinition<TDocument> op)


In general, avoid abbreviations like op.

rstam · 2025-04-09T18:48:46Z

src/MongoDB.Driver/Search/SearchDefinition.cs

+        public static SearchDefinition<TDocument> WithConfiguredSerialization<TDocument>(this SearchDefinition<TDocument> searchDefinition, bool useDefaultSerialization)
+        {
+            if (searchDefinition is not OperatorSearchDefinition<TDocument> op)
+                throw new InvalidOperationException("Default serialization cannot be used with the current SearchDefinition type");


Wrong exception type. Should be NotSupportedException.

Also see enhanced error message in refactoring suggested above.

rstam · 2025-04-09T18:50:49Z

src/MongoDB.Driver/Search/SearchDefinition.cs

        protected readonly SearchPathDefinition<TDocument> _path;
        protected readonly SearchScoreDefinition<TDocument> _score;

+        protected bool _useConfiguredSerialization = false;


My argument above that this should not be configurable has been rejected by Boris.

But... let's name it _useConfiguredSerializers instead.

Search and replace "use configured serialization" with "use configured serializers" everywheren.

rstam · 2025-04-09T18:51:13Z

src/MongoDB.Driver/Search/SearchDefinition.cs

+            RenderArgs<TDocument> args,
+            IBsonSerializer fieldSerializer) => new();
+
+        internal void SetUseConfiguredSerialization(bool useDefaultSerialization)


Parameter name is wrong.

I've renamed it to useConfiguredSerializers as in the other places. I had to change the name of the method to SetUseConfiguredSerializersInternal though, otherwise it would cause confusion (internally) between this and the extension method.

src/MongoDB.Driver/Search/SearchDefinition.cs

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

src/MongoDB.Driver/Search/SearchDefinition.cs

rstam · 2025-04-10T16:56:44Z

src/MongoDB.Driver/Search/SearchDefinition.cs

+                throw new NotSupportedException($"{nameof(SetUseConfiguredSerializers)} cannot be used with SearchDefinition type: {searchDefinition.GetType()}.");
+            }
+
+            operatorSearchDefinition.SetUseConfiguredSerializersInternal(useConfiguredSerializers);


There was no confusion with the existing name. This renaming is not necessary.

Also, see previous comment.

rstam · 2025-04-10T16:57:52Z

src/MongoDB.Driver/Search/SearchDefinition.cs

+        /// <param name="useConfiguredSerializers">Whether to use the configured serializers or not.</param>
+        /// <returns>The same <see cref="SearchDefinition{TDocument}"/> instance with default serialization enabled.</returns>
+        /// <exception cref="InvalidOperationException">Thrown if <paramref name="searchDefinition"/> is not of a valid type/>.</exception>
+        public static SearchDefinition<TDocument> SetUseConfiguredSerializers<TDocument>(this SearchDefinition<TDocument> searchDefinition, bool useConfiguredSerializers)


I agree with your comment that SetXyz usually implies a void return type.

Since WithXyz and SetXyz both have erroneous implications, how about we just go with UseConfiguredSerializers? That seems to read OK when looking at how it is used in the tests.

Sounds good!

rstam · 2025-04-10T16:58:54Z

src/MongoDB.Driver/Search/SearchDefinition.cs

+        /// <param name="searchDefinition">The search definition instance.</param>
+        /// <param name="useConfiguredSerializers">Whether to use the configured serializers or not.</param>
+        /// <returns>The same <see cref="SearchDefinition{TDocument}"/> instance with default serialization enabled.</returns>
+        /// <exception cref="InvalidOperationException">Thrown if <paramref name="searchDefinition"/> is not of a valid type/>.</exception>


The exception type need to be fixed here too:

/// <exception cref="NotSupportedException">Thrown if <paramref name="searchDefinition"/> is not of a valid type/>.</exception>

Or just remove this line. We usually don't include this in our doc comments.

rstam · 2025-04-10T17:00:09Z

tests/MongoDB.Driver.Tests/Search/SearchDefinitionBuilderTests.cs

+
+        [Theory]
+        [MemberData(nameof(InTypedWithConfiguredSerializersTestData))]
+        public void InWithConfiguredSerialization_typed<T>(


Find remaining places where "configuredserialization" or "configured serialization" is used...

It slipped through the cracks, it was the last one 🤦

sanych-sun · 2025-04-10T17:27:03Z

Please add appropriate label to the PR.

rstam

LGTM

papafe · 2025-04-22T11:23:51Z

@rstam @BorisDog I've inverted the boolean controlling the behaviour, so now by default the registered serializers will be used.
I kept the same name for the method controlling this behaviour, as it seems it made the most sense.

BorisDog

LGTM!

rstam

LGTM

sanych-sun · 2025-04-29T22:49:09Z

We should reword the title of the PR, so it would sounds like a feature. For release notes.

papafe · 2025-04-30T13:06:52Z

We should reword the title of the PR, so it would sounds like a feature. For release notes.

@sanych-sun Your comment made me realize that maybe the bug tag is more appropriate for this PR in the current state. We are actually correcting the behaviour of something that is already there AND also adding the possibility of having the previous behaviour. If this had to go in the release notes under only one section, I think it should be "bug".

papafe requested a review from BorisDog December 31, 2024 15:29

papafe commented Jan 2, 2025

View reviewed changes

papafe requested a review from rstam January 2, 2025 16:36

rstam suggested changes Jan 3, 2025

View reviewed changes

papafe commented Jan 6, 2025

View reviewed changes

tests/MongoDB.Driver.Tests/Search/SearchDefinitionBuilderTests.cs Outdated Show resolved Hide resolved

papafe commented Jan 7, 2025

View reviewed changes

src/MongoDB.Driver/FieldValueSerializerHelper.cs Outdated Show resolved Hide resolved

papafe commented Jan 7, 2025

View reviewed changes

tests/MongoDB.Driver.Tests/Search/SearchDefinitionBuilderTests.cs Show resolved Hide resolved

papafe commented Jan 7, 2025

View reviewed changes

src/MongoDB.Driver/Search/SearchDefinition.cs Outdated Show resolved Hide resolved

papafe commented Jan 7, 2025

View reviewed changes

src/MongoDB.Driver/Search/SearchDefinitionBuilder.cs Outdated Show resolved Hide resolved

papafe requested review from rstam and sanych-sun and removed request for BorisDog January 7, 2025 11:42

papafe marked this pull request as ready for review January 7, 2025 15:32

papafe requested a review from a team as a code owner January 7, 2025 15:32

rstam suggested changes Jan 7, 2025

View reviewed changes

papafe commented Jan 8, 2025

View reviewed changes

tests/MongoDB.Driver.Tests/Search/SearchDefinitionBuilderTests.cs Show resolved Hide resolved

papafe requested a review from rstam January 8, 2025 10:24

rstam approved these changes Jan 10, 2025

View reviewed changes

papafe requested a review from BorisDog January 28, 2025 19:52

BorisDog requested changes Feb 4, 2025

View reviewed changes

papafe requested a review from BorisDog February 6, 2025 20:26

BorisDog requested changes Feb 7, 2025

View reviewed changes

papafe force-pushed the charp5442 branch from 1dc887d to ba81027 Compare February 7, 2025 06:46

rstam self-requested a review February 10, 2025 22:19

papafe force-pushed the charp5442 branch from 39a9744 to 8522ef3 Compare February 27, 2025 14:48

Name correction

44a8aa8

rstam suggested changes Feb 27, 2025

View reviewed changes

src/MongoDB.Driver/Search/SearchDefinition.cs Outdated Show resolved Hide resolved

rstam suggested changes Feb 27, 2025

View reviewed changes

src/MongoDB.Driver/Search/SearchDefinition.cs Outdated Show resolved Hide resolved

rstam suggested changes Feb 28, 2025

View reviewed changes

src/MongoDB.Driver/Search/SearchDefinition.cs Outdated Show resolved Hide resolved

papafe requested a review from rstam April 3, 2025 13:54

rstam suggested changes Apr 9, 2025

View reviewed changes

papafe requested review from rstam and sanych-sun April 10, 2025 08:22

papafe added 2 commits April 10, 2025 17:24

Corrections according to PR

647fc30

Rename

614b90a

rstam suggested changes Apr 10, 2025

View reviewed changes

papafe added the feature Adds new user-facing functionality. label Apr 10, 2025

Fixes for PR review

0031e88

papafe requested a review from rstam April 10, 2025 17:44

rstam approved these changes Apr 10, 2025

View reviewed changes

papafe added 2 commits April 22, 2025 13:20

Inverted boolean

e1e6fd8

Small correction.

852b25b

papafe requested a review from rstam April 22, 2025 11:23

BorisDog approved these changes Apr 22, 2025

View reviewed changes

rstam approved these changes Apr 25, 2025

View reviewed changes

papafe added bug Fixes issues or unintended behavior. and removed feature Adds new user-facing functionality. labels Apr 30, 2025

papafe changed the title ~~CSHARP-5442: Atlas Search doesn't respect the correct serializer~~ CSHARP-5442: Fixed use of serializer by Atlas Search operators Apr 30, 2025

papafe merged commit 19aa4dc into mongodb:main Apr 30, 2025
26 of 30 checks passed

papafe deleted the charp5442 branch June 20, 2025 08:09


		var renderedField = _arrayField.Render(args);

		var serializer =

		private readonly IBsonSerializer<TItem> _itemSerializer;

		public IBsonSerializer<TItem> ItemSerializer => _itemSerializer;


		internal virtual (BsonValue, IBsonSerializer) RenderAndGetFieldSerializer(RenderArgs<TDocument> args) => (Render(args), null);

		internal (string renderedPath, IBsonSerializer fieldSerializer) RenderFieldWithSerializer(FieldDefinition<TDocument> fieldDefinition, RenderArgs<TDocument> args)

Conversation

papafe commented Dec 31, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

papafe commented Dec 31, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

papafe Jan 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

papafe Jan 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

papafe Jan 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rstam left a comment

Choose a reason for hiding this comment

Uh oh!

papafe commented Jan 14, 2025

Uh oh!

papafe commented Jan 28, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

papafe Feb 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BorisDog Feb 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

papafe commented Feb 6, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

papafe commented Dec 31, 2024 •

edited

Loading

papafe commented Dec 31, 2024 •

edited

Loading

papafe Jan 2, 2025 •

edited

Loading

papafe Jan 6, 2025 •

edited

Loading

papafe Jan 6, 2025 •

edited

Loading

papafe Feb 5, 2025 •

edited

Loading

BorisDog Feb 5, 2025 •

edited

Loading