Skip to content

Conversation

@sarahlwelton
Copy link
Contributor

Ticket came in asking if we could clarify for users what happens when their field names contain periods and they try to use those with mappings in the Search Service.

Decided best course of action was a new page describing the mapping types in more details, with the impact periods have on each type.

Updated links and removed redundant info to support that.

Preview URL:
https://preview.docs-test.couchbase.com/docs-devex-DOC-13923-field-names-with-periods/server/current/search/about-mappings.html

You will need the Docs Team credentials on Confluence.

…hat used to point to customize-index.adoc to point to about-mappings.adoc, instead. Remove repetitive info from customize-index.adoc.
…wn the page. Update more links, this time for XATTRs mapping explanation
@sarahlwelton sarahlwelton self-assigned this Jan 29, 2026
Copy link

@abhinavdangeti abhinavdangeti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sarahlwelton I've added a few comments, let me also ping @capemox here (who set up the DOC ticket) so he can share his feedback on this as well.

A type mapping includes or excludes specific documents in a collection from an index.
A document must match the collection and document type set by a type mapping to be included in a Search index.

You can control the type of a document by xref:search:set-type-identifier.adoc[setting a type identifier].

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth stating this is optional perhaps.


=== Collection Names

You cannot use a collection name that contains a period (`.`) in a Search index type mapping.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

KV forbids this already - so it shouldn't be a problem downstream.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good to know - I'm going to tweak this to specify the "collection type mapping name", instead - because I still think it's worthwhile to explain how this mechanism works.

You cannot use a collection name that contains a period (`.`) in a Search index type mapping.

The Search Service uses periods (`.`) to separate collection names from xref:search:customize-index.adoc#type-identifiers[type identifiers].
If you used a collection name that contained a period, the Search Service would interpret anything after the period as a filter value on your type mapping.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto.

include::example$about-mappings.jsonc[lines=1..8]
----

If you tried to create an object mapping for another object called `origin.country`, the Search Service would return results from that mapping alongside the nested `country` field in the `origin` object.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I quite follow this line.

  • What ends up happening in this situation is we'd have same field index for both the fields with name - origin.country and country nested within origin field mapping.
  • During evaluation of an analytic query, we could even fail to determine the right analyzer for origin.country if country were not created within origin - leading to indeterministic behavior.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have taken another stab at explaining this - this breakdown was helpful :) The ticket was a little light on details on what the problematic mechanism actually was, so I admit I was somewhat guessing - lol.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants