[DOCS-11460] Use transaction terminology for Change Streams full_document behavior Created: 15/Mar/18 Updated: 30/Oct/23 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | change stream, manual, Server |
| Affects Version/s: | 4.0 Core Server |
| Fix Version/s: | Server_Docs_20231030 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Matt Lord (Inactive) | Assignee: | Kay Kim (Inactive) |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: | |
| Days since reply: | 1 year, 14 weeks, 2 days ago |
| Epic Link: | DOCSP-1769 |
| Description |
|
Clarify the transaction isolation level used with the full_document option in MongoDB 4.0 and later. This would indicate that the full document lookup is done in a new transaction [context] using local read-committed isolation (+ writeConcern:majority), so it will always return the latest committed (and durable) version of the document. We do explain this today, but IMO it could be more clear in a transactional context for 4.0+ (mostly about language and terminology). I think that the average user will naturally expect full_document to operate on the same snapshot as the actual update (a single transaction operating in repeatable-read/snapshot isolation for the write and read, as a typical trigger would), so we probably can't be too clear on this. |
| Comments |
| Comment by Education Bot [ 31/Oct/22 ] |
|
Hello! This ticket has been closed due to inactivity. If you believe this ticket is still important, please reopen it and leave a comment to explain why. Thank you! |
| Comment by Charlie Swanson [ 15/Mar/18 ] |
|
Ok - this argument makes sense. I would just push to clearly separate when we are referring to "what most people think of as a transaction" and "A MongoDB Transaction". I think you've convinced me that someone unfamiliar with MongoDB would find it easier to reason about the update lookup if we mentioned it was a separate operation or transaction. However, if we use the same or similar terms to the MongoDB terms we risk confusing someone who is only familiar with MongoDB. |
| Comment by Matt Lord (Inactive) [ 15/Mar/18 ] |
|
There's a difference between: IMO, we are trying to attract #2 by adding support for transactions. We're going after the larger database market, which consists of database users. Transactions are a basic feature that many database users just expect – you don't do anything outside of a transaction (context), otherwise it's "chaos". I don't expect #1 to really require much of anything in the way of docs, but #2 certainly does. It's of course up to you, I'm just trying to provide the viewpoint an average database user would have when examining MongoDB as a potential database choice, or the Change Streams feature as a viable Change-Data-Capture implementation. They don't need to know the internal implementation details – e.g. " {level: "majority", afterClusterTime: <time of change>}" – they just need to understand how the feature works in language they understand. |
| Comment by Charlie Swanson [ 15/Mar/18 ] |
|
I would encourage any clarification that would make it more obvious, but your proposed wording is weird to me. Change streams are not run in a "transaction" or "context". You are not allowed to open a change stream within a transaction in the 4.0+ sense, and I'm not sure "context" is a meaningful word. The most specific I'd know how to be is that each update lookup is performed with readConcern: {level: "majority", afterClusterTime: <time of change>}. It will definitely not be the exact version of the document after being updated - that should be made as clear as possible. |