[DOCS-11561] Docs for SERVER-33818: Add 'startAtOperationTime' as an option in $changeStream Created: 09/Apr/18  Updated: 29/Oct/23  Resolved: 24/Jun/18

Status: Closed
Project: Documentation
Component/s: None
Affects Version/s: None
Fix Version/s: 3.7.4

Type: Task Priority: Major - P3
Reporter: Kay Kim (Inactive) Assignee: Kay Kim (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-33818 Add 'startAtOperationTime' as an opti... Closed
Duplicate
is duplicated by DOCS-11715 Docs for SERVER-34818: changeStream o... Closed
Related
is related to DOCS-11616 Docs for SERVER-34313: Change resume ... Closed
is related to DOCS-11715 Docs for SERVER-34818: changeStream o... Closed
Participants:
Days since reply: 5 years, 33 weeks, 3 days ago
Epic Link: DOCS: 4.0 Server

 Description   

Documentation Request Summary:

No documentation summary in engineering ticket

Engineering Ticket Description:

This will make it more clear that we support this option.



 Comments   
Comment by Githook User [ 24/Jun/18 ]

Author:

{'username': 'kay-kim', 'name': 'kay', 'email': 'kay.kim@10gen.com'}

Message: DOCS-11561,DOCS-11760: startAtOperationTime, ``txnNumber`` and the ``lsid`` fields
Branch: master
https://github.com/mongodb/docs/commit/62e8fee82f48037778f557ecd5975873dff4f799

Comment by Ian Whalen (Inactive) [ 31/May/18 ]

just a note that we changed the summary to "Add 'startAtOperationTime' as an option in $changeStream"

Comment by Charlie Swanson [ 12/Apr/18 ]

You cannot use both of them at once - sorry if my wording was unclear. When I say "just" the cluster time, I mean that a resume token includes the cluster time, so a resume token is strictly more specific than a clusterTime.

Comment by Ravind Kumar (Inactive) [ 12/Apr/18 ]

charlie.swanson is that to say you can specify this option without a resume token? Can it also be used with a resume token? Or are the two options mutually exclusive.

Comment by Charlie Swanson [ 12/Apr/18 ]

Agreed, we should not encourage usages of this. But I think we should certainly document that it's useful if you want to be able to resume your stream before any changes are seen. I would also like if we included some wording and warning about how if you just use the cluster time, there may be multiple things that happened at that cluster time in a sharded cluster, so you could get duplicate entries.

Comment by Nicholas Zolnierz [ 11/Apr/18 ]

ravind.kumar your understanding is mostly correct, except the format is the internal BSON timestamp, which is included in the response of some (most?) commands. The basic use case for the drivers is specified nicely in the design doc, I'll paste it here for reference:

  • Obtain a cluster time from the cluster. Any command (e.g. ismaster) will return the cluster time in the $clusterTime field.
  • Start all change streams with a 'startAtClusterTime', and remember that time.
  • As soon as the first change (with the first resume token) is returned, they no longer have to track that time, instead remembering the resume token as they do today.
  • If there is an error before the first change, they should resume with 'startAtClusterTime' and the original cluster time. If there is an error after the first change, they should resume with 'resumeAfter' and the resume token.

If I understand correctly, I don't think we want to advise end users to use this interface directly but instead to use a resume token if possible. charlie.swanson do you agree?

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