[GODRIVER-1733] Parse and expose all four lastWrite fields Created: 30/Aug/20  Updated: 30/Mar/22

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

Type: New Feature Priority: Major - P3
Reporter: David Bartley Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GODRIVER-41 Implement SDAM Monitoring specification Closed

 Description   

We're looking into writing a custom read preference/ServerSelector for our mongo proxy, based on lastWrite.majorityOpTime (basically, we'd like to treat "afterClusterTime" more like read preference, and only select a server if we know it can satisfy this read concern). Currently, the driver only parses and exposes lastWrite.lastWriteDate (as description.Server.LastWriteTime). It'd be great if majorityOpTime were also added to description.Server (as e.g. MajorityOpTime primitive.Timestamp). And, at that point we may as well expose the other two fields (opTime and majorityWriteDate).

Happy to provide a patch if this seems reasonable!



 Comments   
Comment by Divjot Arora (Inactive) [ 08/Sep/20 ]

bartle Just wanted to let you know that the PR has been merged. I'm going to move this ticket into Open for now. If you want to open a PR for it, I can move it into code review once that's up.

Comment by David Bartley [ 31/Aug/20 ]

Sounds good, I'll look into writing a PR once that's merged.

Comment by Divjot Arora (Inactive) [ 31/Aug/20 ]

Thanks for the quick response! Are you still open to submitting a PR for this? It's probably best to wait until https://github.com/mongodb/mongo-go-driver/pull/494 is merged, which moves the description package and some related packages from x to be sub-packages of mongo. If you aren't able to submit a PR, we'll likely backlog this and get back to it once we've completed some other work we have planned for the 1.5.0 cycle.

Comment by David Bartley [ 31/Aug/20 ]

Yes, storing the raw doc seems reasonable.

Comment by Divjot Arora (Inactive) [ 31/Aug/20 ]

Hi bartle,

I'd prefer to avoid adding more information to the description.Server type, especially if that information involves additional fields that aren't actually used by the driver. I understand that these fields are important for your proxy, so one proposal is to store the entire isMaster response in description.Server and add a getter for the raw BSON document. Your proxy can then directly use any fields that are already on description.Server and can parse additional fields from the response document. Does that sound reasonable?

– Divjot 

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