[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: |
|
||||||||
| 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 |