CSHARP-6020: Add builders for the doesNotAffect field for in, range, equals and compound Atlas Search operators#2032
CSHARP-6020: Add builders for the doesNotAffect field for in, range, equals and compound Atlas Search operators#2032sanych-sun wants to merge 4 commits into
Conversation
…ls and compound Atlas Search operators
There was a problem hiding this comment.
Pull request overview
This PR adds support for rendering Atlas Search’s doesNotAffect option across several operators so facet counts can be computed over the full result set even when certain operators are applied.
Changes:
- Added
doesNotAffectrendering forequals,in, andrangeoperators, plus a fluentDoesNotAffect(...)builder forcompound. - Introduced new
SearchDefinitionBuilderoverloads to acceptdoesNotAffectforEquals,In, andRange. - Added unit and Atlas integration tests validating
doesNotAffectrendering and behavior.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 24 comments.
Show a summary per file
| File | Description |
|---|---|
| tests/MongoDB.Driver.Tests/Search/SearchDefinitionBuilderTests.cs | Adds rendering tests for doesNotAffect on compound, equals, in, and range. |
| tests/MongoDB.Driver.Tests/Search/AtlasSearchTests.cs | Adds Atlas integration coverage for doesNotAffect with facets; introduces Movie.Year mapping. |
| src/MongoDB.Driver/Search/SearchDefinitionBuilder.cs | Adds public overloads for doesNotAffect; updates (and in several cases regresses) XML docs around SearchPathDefinition. |
| src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs | Implements doesNotAffect serialization for Compound, Equals, In, and Range operator definitions. |
| src/MongoDB.Driver/Search/CompoundSearchDefinitionBuilder.cs | Adds fluent DoesNotAffect(string facetName) to the compound builder and passes it through to rendering. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| public SearchDefinition<TDocument> Equals<TField>( | ||
| FieldDefinition<TDocument, TField> path, | ||
| TField value, | ||
| IEnumerable<string> doesNotAffect, | ||
| SearchScoreDefinition<TDocument> score = null) => |
There was a problem hiding this comment.
Do not agree. Even though this looks like ambiguous call, having 3rd parameter as null should resolve to the overload with SearchScoreDefinition parameter. However it does not really matter what overload will be selected - it will result in call having both score and doesNotAffect having null as a value.
We probably should consider builder pattern here for future, but it would be a breaking change - so not in scope of this PR, but might be a good idea for major release.
There was a problem hiding this comment.
Reworked the added parameter as Options struct instead. CC: @BorisDog
| : base(OperatorType.Equals, path, score) | ||
| { | ||
| _value = value; | ||
| _doesNotAffect = doesNotAffect?.ToArray(); |
| { | ||
| Ensure.IsNotNullOrEmpty(values, nameof(values)); | ||
| _values = values.ToArray(); | ||
| _doesNotAffect = doesNotAffect?.ToArray(); |
| : base(OperatorType.Range, path, score) | ||
| { | ||
| _range = range; | ||
| _doesNotAffect = doesNotAffect?.ToArray(); |
No description provided.