[DRIVERS-1340] Allow hint for unacknowledged writes using OP_MSG when supported by the server Created: 20/Jul/20 Updated: 22/Jun/22 |
|
| Status: | Implementing |
| Project: | Drivers |
| Component/s: | CRUD |
| Fix Version/s: | None |
| Type: | Spec Change | Priority: | Minor - P4 |
| Reporter: | Jeremy Mikola | Assignee: | Jeremy Mikola |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | leads-triage | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Driver Changes: | Needed | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Downstream Changes Summary: | Drivers should no longer prohibit using hint with an unacknowledged write concern for update, delete, and findAndModify commands (issued via OP_MSG) and related helpers (e.g. UpdateOne, bulkWrite, findOneAndDelete) if hint is known to be supported by the server executing the operation (i.e. 4.2+ for update commands, 4.4+ for delete and findAndModify). Drivers should sync unified CRUD tests with mongodb/specifications@59a5dad Drivers (like Java, for example) that ignore unacknowledged write concern for findOneAndReplace/Update/Delete helpers should skip the following tests:
because those tests are assuming that the driver includes writeConcern: {w : 0 } in the findAndModify command and that, as a result, the server response with only ok: 1 and therefore value is unset. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Driver Compliance: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
This reverts DRIVERS-991, which instructed drivers to raise a client-side error when the hint option is provided with an unacknowledged write issued against any server version. When the the server is known to support hint (i.e. 4.2+ for update, 4.4+ for delete), drivers should allow the option to be specified. They should only report an error for earlier server versions where the server is known to not support the option and an error would otherwise not be returned because of the nature of unacknowledged writes. Previous arguments relating hint to existing treatment of arrayFilters and collation aren't relevant, because their documentation refers to "unacknowledged writes using OP_UPDATE" (where the option cannot be expressed). Those options don't refer to OP_MSG at all, because they were both supported by all server versions that support OP_MSG. hint can retain the language about OP_UPDATE, but its OP_MSG language should be revised to only mandate an error on unsupported server versions. Lastly, the following Q&A should be revised:
This is a poor argument as incorrectly formatted options can just as easily apply to the filter or update/replacement arguments (e.g. using an invalid query operator). It's one thing to raise a client-error when the driver knows for certain that a server option is not supported, but the current strategy is presumptive. We should also update the language for findAndModify in the CRUD spec (since it does refer to behavior of unacknowledged write concerns). findAndModify support for hint requires 4.4+ (see: }} response, which hides any error if hint is unsupported or invalid (e.g. no such index). With respect to this issue, we need only concern ourselves with whether hint is supported, so raising an error if hint is used on a pre-4.4 server with an unacknowledged write concern is sufficient. SummaryThis issue was originally reported after starting work on language tickets for DRIVERS-991, which asked drivers to raise client-side errors for any use of hint with unacknowledged writes. This ticket seeks to revert that change and make an allowance for cases where drivers know that the server does support the hint option. Since DRIVERS-991 was filed, libmongoc and dependent drivers have chosen not to implement that ticket and are instead waiting on this ticket to be resolved. This ticket has languished for more than a year since and remains outstanding. MotivationWho is the affected end user?Applications that would like to utilize hint options with unacknowledged writes. How does this affect the end user?The behavior is currently prohibited by our specifications despite being possible to implement. In hindsight, it was premature to add the blanket prohibition. How likely is it that this problem or use case will occur?A minority of applications make individual use of hint and unacknowledged writes. The intersection of applications using both features together is even rarer. If the problem does occur, what are the consequences and how severe are they?Inability to execute a supported operation. Is this issue urgent?No. Is this ticket required by a downstream team?No. Is this ticket only for tests?This ticket affects both driver functionality and our spec tests. |
| Comments |
| Comment by Jeremy Mikola [ 06/Dec/21 ] | |||||||||||||||
|
Documentation for the value result field only talks about null and document values. It does not mention that the value field will be entirely omitted if findAndModify specifies an unacknowledged write concern, as shown below:
I'll note that the CRUD spec currently documents the return value of findAndModify helpers as "Document" and doesn't seem to discuss a possible null return value at all. SPEC-148 is an old ticket that talked about that inconsistency and claims to have addressed it but it's not cross-referenced with any commit that I could find. As far as handling non-existent results (i.e. value is omitted instead of being null), I created
I'm not aware of any guidance that drivers set moreToCome for findAndModify commands. With respect to unacknowledged write concerns, I've only seen moreToCome used with the insert, update, and delete commands. Like most other commands, findAndModify always returns a result (even if just {ok:1}). The CRUD spec itself never addresses the wire protocol for the underlying commands, which is why I didn't bother to talk about this in the spec changes associated with this ticket.
I think it's still sensible to prohibit hint and {w:0} when we know hint is unsupported. This was originally requested as a safeguard for users since they might otherwise never realize their command failed to execute, and the purpose of this issue was simply to relax that restriction when drivers know that hint is supported by the server. With all that said, I'm failing to see how $$unsetOrMatches would be problematic for drivers. Whether a driver decides to return null or nothing at all (for languages that make such a distinction), that assertion should be satisfied. | |||||||||||||||
| Comment by Githook User [ 31/Aug/21 ] | |||||||||||||||
|
Author: {'name': 'Jeremy Mikola', 'email': 'jmikola@gmail.com', 'username': 'jmikola'}Message: DRIVERS-1340: Allow w:0 and hint if supported by server (#1057) update supports hint on 4.2+. delete and findAndModify support hint on 4.4+. Add APM assertions for successful commands to ensure that w:0 is actually used. Co-authored-by: Benjamin Rewis <32186188+benjirewis@users.noreply.github.com> | |||||||||||||||
| Comment by Jeremy Mikola [ 26/Aug/21 ] | |||||||||||||||
|
Cross-referencing with the related tickets for introducing support for hint on update, delete, and findAndModify comands. The spec tests for this issue will depend on those features being implemented, so it makes sense to model this as an issue dependency. | |||||||||||||||
| Comment by Jeremy Mikola [ 26/Aug/21 ] | |||||||||||||||