Add builder support for the $score aggregation stage

XMLWordPrintableJSON

    • Type: New Feature
    • Resolution: Unresolved
    • Priority: Unknown
    • None
    • Component/s: CRUD
    • None
    • Builder Changes Needed

      Description:

      Summary

      Add driver support for the $score aggregation pipeline stage. $score computes a value from each document and attaches it as score metadata (accessible via {$meta: "score"}), with optional normalization,
      weighting, and breakdown details. It can be placed anywhere in an aggregation pipeline; in particular, it is a primary way for users to produce scored input pipelines for $rankFusion / $scoreFusion, where
      input pipelines must begin with $search / $vectorSearch / $score.

      Motivation

      Who is the affected end user?

      Application developers using drivers to build aggregation pipelines that compute or attach a score, particularly anyone composing fusion pipelines that mix $search / $vectorSearch with $score as a fusion
      input.

      How does this affect the end user?

      Annoyed and inconsistent — they have idiomatic builders for $rankFusion / $scoreFusion but must drop into raw BSON to express the input pipelines those builders need. The asymmetry undermines the value of the
      fusion-stage builders.

      How likely is it that this problem or use case will occur?

      Main path for users adopting fusion. Probability of hitting this is essentially the probability of using $rankFusion / $scoreFusion at all, plus any user attaching custom score metadata in standalone
      aggregation work.

      If the problem does occur, what are the consequences and how severe are they?

      Friction and inconsistency; no severe runtime consequence. Slower time-to-first-pipeline for new fusion adopters, raw-BSON snippets in user code.

      Is this issue urgent?

      Not deadline-urgent. Should land alongside or shortly after fusion stage builder support to avoid shipping a half-built API surface.

      Is this ticket required by a downstream team?

      Not directly required by Atlas / Shell / Compass, but Atlas tutorials and Compass examples will likely showcase it.

      Is this ticket only for tests?

      No — functional builder API work.

      Acceptance Criteria

      Defined $score stage builder API surface in each driver, covering the supported parameters: score (expression), normalization (string; supported values: none, sigmoid,
      minMaxScaler), weight (double, optional), and scoreDetails (boolean, optional).

            Assignee:
            Unassigned
            Reporter:
            Adelin Mbida Owona
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: