[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:
1. What makes sense to someone deeply embedded in the MongoDB space
2. What makes sense to someone familiar with databases in general

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.

Generated at Thu Feb 08 08:02:51 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.