[DOCS-4788] Rationalize language for tags and tag sets Created: 06/Feb/15 Updated: 30/Oct/23 Resolved: 03/Apr/15 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual |
| Affects Version/s: | None |
| Fix Version/s: | Server_Docs_20231030 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | David Golden | Assignee: | Andrew Aldridge |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: | |
| Days since reply: | 8 years, 45 weeks, 5 days ago |
| Description |
|
As part of my work on the Server Selection Spec, I've introduced a standard terminology for discussing tags and tags sets. I think this should be used to revise all the MongoDB manual documentation that discusses tags.
For example, read preferences optionally include a tag set list (except mode 'primary'). The first tag set in the list that matches at least one secondary in the replica set is used to choose secondaries eligible for reads. In particular, the manual should be careful using the term "tags", which has sometimes been used to mean "tag set" and sometimes to mean "tag set list". Ideally, it would only refer to multiple key value pairs and not to a complete tag set document. That allows clearer explanation of things like tag set matching. E.g. if all the tags (i.e. key/value pairs) in tag set A are present in tag set B, then A matches B. As an example of where "tags" confusion lies, for a replica set member, the "tags" field is a tag set. But in the read preference query modifier "tags" is a tag set list:
While we can't change the server's use of "tags", we can try to be clearer in the documentation. |
| Comments |
| Comment by Githook User [ 03/Apr/15 ] |
|
Author: {u'username': u'i80and', u'name': u'Andrew Aldridge', u'email': u'i80and@foxquill.com'}Message: |