[SERVER-27190] add $throw/$error as pipeline operator Created: 28/Nov/16  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Aggregation Framework
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Adinoyi Omuya Assignee: Backlog - Query Optimization
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query Optimization
Participants:

 Description   

There are cases where MongoDB's behavior is inconsistent with a user's expectation and in such cases, it would be helpful if the user could force the aggregation framework to return an error - instead of having operations proceed.

An example is the power function:

db.xy.aggregate({"$project":{"pow":{ "$pow": [ -2, 4.4 ] }}})
{
  "result": [
    {
      "_id": ObjectId("56d4699e3a0b52029321e0d5"),
      "pow": NaN
    },
  ],
  "ok": 1
}

Other relational databases - e.g. MySQL - return an error:

ERROR 1690 (22003): DOUBLE value is out of range in 'pow(-(2),-(4.4))'

It would be helpful if I could write something like:

{
  "$project": {
    "pow": {
      "$cond": [
        {
          "$eq": [
            {
              "$pow": [
                -2,
                4.4
              ]
            },
            NaN
          ]
        },
        {
          "$throw": "invalid operation"
        },
        "good"
      ]
    }
  }
}



 Comments   
Comment by Charlie Swanson [ 30/Nov/16 ]

I think this should be treated as a more general request to allow users to cause a pipeline to fail based on some computed condition. If we're only interested in different $pow semantics or some other subset, we should track that work in a separate ticket.

Comment by Asya Kamsky [ 30/Nov/16 ]

Is the issue that we should be throwing an error on invalid expression (the way MySQL does)?

Or is it a more general "we need a way to allow pipeline to throw an error" and this was just an example?

Generated at Thu Feb 08 04:14:25 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.