[GODRIVER-2619] Allow application to have continued access to for ChangeStream.Current without extra copy Created: 26/Oct/22  Updated: 27/Oct/23  Resolved: 28/Mar/23

Status: Closed
Project: Go Driver
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Wenbin Zhu Assignee: Preston Vasquez
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Quarter: FY24Q1

 Description   

Currently if applications want to have continued access to ChangeStream.Current after calling Next/TryNext, they have to make a copy of it. This is every inefficient for applications that usually get large change events, and continued access for change streams is very common, for example putting the current event to a queue for async processing. It seems that the reason we have to do this is because the ChangeStream.Current slice can be overwritten, so this ticket is to improve the implementation to avoid applications doing extra copy.



 Comments   
Comment by PM Bot [ 28/Mar/23 ]

There hasn't been any recent activity on this ticket, so we're resolving it. Thanks for reaching out! Please feel free to comment on this if you're able to provide more information.

Comment by PM Bot [ 13/Mar/23 ]

Hey wenbin.zhu@mongodb.com, We need additional details to investigate the problem. If this is still an issue for you, please provide the requested information.

Comment by Wenbin Zhu [ 03/Mar/23 ]

preston.vasquez@mongodb.com C2C does use a buffered channel for async event processing, the problem is that we need to make a deep copy of the event before putting into the channel because cs.Current slice can be overwritten (see this comment).

Sending on the channel would still copy data under the hood

I'm a bit skeptical about this. The change event is basically a slice, and IIUC sending on channel only copies the slice data structure which is a shallow copy, it doesn't copy the actual array backing the slice. According to this comment, it seems we need to do a deep copy instead of a shallow one to be safe. C2C currently does a deep copy of the event before putting it into the buffered channel, and we'd like to avoid such deep copy.

Comment by Wenbin Zhu [ 26/Oct/22 ]

I'm not sure if doing this improvement would result in API changes, I hope it doesn't have to.

Comment by Wenbin Zhu [ 26/Oct/22 ]

C2C can benefit from this when customers have large change events.

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