MarkLogic Server 11.0 Product Documentation

Database Field Configuration Help

A Field specifies a named object that has its own index term lists and can be searched with the query constructor cts:field-word-query. Use this configuration to specify if the field is built using paths or from the root of a document. In most cases, paths are the preferred way to build a field. You can specify multiple paths for a field, and each path can have a weight to boost or lower relevance scores for searches with matches in that path. To add or remove index options to the field, you can check or uncheck index options you want to add or remove. You can create field range indexes, define word lexicons, and specify overrides for how to tokenize content using the Database Fields Configuration page. You can also specify XML elements or JSON properties to include or exclude from the field, specify query weights that apply to specific XML elements or JSON properties for relevance calculations, and constrain which XML elements are included or excluded by a specified attribute value.

The bold type on any index setting name indicates that the index setting is inherited from the database configuration.

The following are the configuration options:

• field name specifies the name of the field.

---



• include document root specifies if this field should begin including XML elements or JSON properties at the root for each document (unless explicitly excluded). This is set to false by default, which means you must explicitly include some XML elements or JSON properties for the field to have any content. A field that has include document root specification cannot have field paths.

• field path specifies root of an instance of the field in a document. A field can have one or more field paths. Each field path locates entry points to one or more field instances in the document. Different field paths may point to different kinds of instances in the document. A field can have either field paths or include-root specification. Word query can have only include-root specification.

• stemmed searches specifies whether index terms should be included in the database files to support stemming. When set to basic, basic stemming is enabled, and the shortest stem of each word is indexed. When set to advanced, all stems of each word are indexed. When set to decompounding, all stems are indexed, and smaller component words of large compound words are also indexed. Each successive level of stemming improves recall of word searches, but also causes slower document loads and larger database files.
• word searches specifies whether index terms should be included in the database files to support fast word searches. When this parameter is true, word searches are faster, but document loading is slower and the database files are larger.
• field value searches specifies whether index data is included which speeds up the performance of field value queries that use the cts:field-value-query function. Turn this index off if you are not interested in field value queries and if you want to conserve disk space and decrease loading time.
• field value positions specifies whether index data is included which speeds up the performance of proximity queries that use the cts:field-value-query function. Turn this index off if you are not interested in proximity queries and if you want to conserve disk space and decrease loading time.

---



• fast phrase searches specifies whether index terms should be included in the database files to support fast phrase searches. When this parameter is true, phrase searches are faster, but document loading is slower and the database files are larger.
• fast case sensitive searches specifies whether index terms should be included in the database files to support fast case-sensitive searches. When this parameter is true, case-sensitive searches are faster, but document loading is slower and the database files are larger.
• fast diacritic sensitive searches specifies whether index terms should be included in the database files to support fast diacritic-sensitive searches. When this parameter is true, diacritic-sensitive searches are faster, but document loading is slower and the database files are larger.

---



• trailing wildcard searches specifies whether indexes should be created to enable wildcard searches where the search pattern contains one or more consecutive non-wildcard characters at the beginning of the word, with the wildcard at the end of the word (for example, abc*). When this parameter is true, character searches are faster, but document loading is slower and the database files are larger.
• trailing wildcard word positions specifies whether index data should be included in the database files to enable proximity searches (cts:near-query) within trailing wildcard queries. You must also enable trailing wildcard searches in order to perform trailing wildcard position searches. When this parameter is true, positional searches are possible within a trailing wildcard query, but document loading is slower and the database files are larger.
• three character searches specifies whether indexes should be created to enable wildcard searches where the search pattern contains three or more consecutive non-wildcard characters (for example, abc*). When combined with a codepoint word lexicon, speeds the performance of any wildcard search (including searches with fewer than three consecutive non-wildcard characters). MarkLogic recommends combining the three character search index with a codepoint collation word lexicon. When this parameter is true, character searches are faster, but document loading is slower and the database files are larger.
• three character word positions specifies whether index data should be included in the database files to enable proximity searches (cts:near-query) within wildcard queries. You must also enable three character searches in order to perform wildcard position searches. When this parameter is true, positional searches are possible within a wildcard query, but document loading is slower and the database files are larger.
• two character searches specifies whether indexes should be created to enable wildcard searches where the search pattern contains two consecutive non-wildcard character (for example, ab*). This index is not needed if you have three character searches and a word lexicon.
• one character searches specifies whether indexes should be created to enable wildcard searches where the search pattern contains a single non-wildcard character (for example, a*). This index is not needed if you have three character searches and a word lexicon.

---



• word lexicons specifies the word lexicons to keep or to add for this configuration. You can have multiple word lexicons in a database or a field, each with different collations. To add a new lexicon, enter the collation for the lexicon in the [add] box (for example, http://marklogic.com/collation/ for the UCA Root Collation, which is a sensible collation for many applications). To remove a lexicon, uncheck the [keep] box for the lexicon you want to remove. The specified collation is used to order the words in the lexicon. Each lexicon contains a list of unique words in the database or field, where uniqueness is determined based on the collation chosen. Typically, the specified collation is case-sensitive and diacritic-sensitive so that there are different entries for Ford and ford. Also speeds up wildcard searches. Works in combination with any other available wildcard indexes to improve search index resolution and performance. When used in conjunction with the three character search index, improves wildcard index resolution and speeds up wildcard searches.

---



• included elements are XML elements or JSON properties that should be indexed by this field (i.e. XML elements or JSON properties that will be searched when searching this field).
• excluded elements are XML elements or JSON properties that should not be indexed by this field (i.e. XML elements or JSON properties that will not be searched when searching this field).