[DRIVERS-2103] Deprecate "$out Aggregation Pipeline Operator" spec? Created: 28/Aug/15 Updated: 09/Aug/22 Resolved: 09/Aug/22 |
|
| Status: | Closed |
| Project: | Drivers |
| Component/s: | Server Selection |
| Fix Version/s: | None |
| Type: | Spec Change | Priority: | Minor - P4 |
| Reporter: | Hannes Magnusson | Assignee: | Jeremy Mikola |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Driver Changes: | Not Needed | ||||||||
| Description |
|
https://github.com/mongodb/specifications/blob/master/source/out-aggregation-pipeline-operator.rst Is this spec still applicable? The Read Preference part seems like the meat of the spec, so without it, it should be deprecated/removed? |
| Comments |
| Comment by Patrick Freed [ 09/Aug/22 ] |
|
The $out Aggregation Pipeline Operator spec was removed in DRIVERS-823 |
| Comment by Jeffrey Yemin [ 29/Jan/18 ] |
|
Let's delete this spec and remove any reference to it in the server selection specification. |
| Comment by Emily Stolfo [ 09/Sep/15 ] |
|
Sorry for the delay - I just talked to David about this and am catching up with the discussion. I'll take a look at the spec and see if any (wording) changes need to be made to be consistent with the SS spec. |
| Comment by Bernie Hackett [ 02/Sep/15 ] |
|
That seems like a good reason not to reroute aggregate with $out and instead let it fail if the user uses the wrong read preference (which I believe is the expected behavior from SS). |
| Comment by Hannes Magnusson [ 02/Sep/15 ] |
|
One thing I noticed in the spec too.
And then links to DRIVERSOLD-72 (formerly known as DRIVERS-84).
Which does not issue such warning. The implied notification to the user that the following read from the $out collection will fail is therefore never issued. |
| Comment by David Golden [ 01/Sep/15 ] |
|
emily.stolfo@10gen.com, there's been a bunch of discussion about how this spec should be read in concert with Server Selection. On the Drivers flowdock, there seems to be some consensus that this is the right behavior:
Given that clarification, I'm not sure the warning makes sense anymore, either. As you were the author, could you please amend it and then see about getting it marked "approved"? Perhaps barrie and rathi.gnanasekaran can suggest a shorter spec approval process for this amendment. |
| Comment by David Golden [ 31/Aug/15 ] |
|
I think you're reading more into the SS spec than is there. SS says this about $out:
That's an informational comment, not a normative requirement. The SS spec only says that aggregate without $out is "may-use-secondary". The omission of specific rules for $out was done intentionally so as to not break whatever legacy driver behavior existed for $out. The $out spec says that when $out is given, then the aggregation is a write command and routes to the primary – which is exactly consistent with the SS rules for write commands (which always ignore read preferences). It additionally says that a warning needs to be issued if $out is given with a read pref other than 'primary'. That's an API choice and the SS spec has nothing to say about that. I'd have no objections whatsoever to someone revising the $out spec to use the newer terminology and clarify that when $out is present, aggregate is a write command, and when it's omitted, then aggregate is a 'may-use-secondary' read command. |
| Comment by Hannes Magnusson [ 31/Aug/15 ] |
|
Either we must redirect to the primary, as per the $out aggregation spec, or we must leave it to the user, as per SS. Either we violate the $out aggregation spec by apply the user read preference. |
| Comment by David Golden [ 31/Aug/15 ] |
|
I think it's applicable. SS leaves it up to "the user" to define how to handle aggregate with $out. The aggregation spec says "redirect to primary and warn", which is saving the user from doing the wrong thing. I don't think there's a conflict. |