[DOCS-16097] [SERVER] Document better the limitations of using "." inside field names Created: 05/May/23  Updated: 22/Jan/24

Status: Backlog
Project: Documentation
Component/s: manual, Server
Affects Version/s: 5.0.0, 6.0.0, 6.3.0, 7.0.0
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Alberto Massari Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: backlog, feature, query, security, sharding
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-76875 Exclude fields containing dots from i... Closed
Participants:
Days since reply: 39 weeks, 6 days ago

 Description   

The documentation at Field Names with Periods (.) and Dollar Signs ($) — MongoDB Manual documents the changes done to version 5.0 as part of the PM-1856 initiative. The scope document (Scope: Mitigate pain of using field names with dots and dollars - Google Docs) says:

 

  • We should clearly state in our documentation that field names with dots and dollars are allowed, but discouraged, since some of the features may not be supported with such fields, such as indexing and FLE. Performance may also be suboptimal if field names have to be re-evaluated from an expression for each input document.

 

but the documentation convert this action into a section

 

General Restrictions

In addition to the storage validation rules above, there are some general restrictions on using dollar ($) prefixed field names. These fields cannot:

  • Be indexed
  • Be used as part of a shard key
  • Be be modified with an escape sequence
  • Be used as a subfield in an _id document

 

that begins with the "restrictions on using dollar ($) prefixed field names", hinting that fields containing dots in the name can be indexed or encrypted.

The preamble to the restrictions section should be widened to include dots, without leaving the user with the doubt whether the entire page is for both cases or only for $-prefixed names


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