Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DOCS-7818] Add info about case-sensitivity of searches #1610

Merged
merged 1 commit into from
Dec 2, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
[DOCS-7818] Add info about case-sensitivity of searches
  • Loading branch information
mbujak-hyland committed Nov 28, 2024
commit bb93e5158e413564126264dce2c363a1c5e162a7
Original file line number Diff line number Diff line change
Expand Up @@ -429,7 +429,7 @@ The following table describes all the parameters that can be used when defining
|`mandatory`|element (boolean)|`[0..1`]|`true` = when a property is set as mandatory it tells Content Services that the property is required. By default, this is not enforced. Instead, Content Services marks content items with empty mandatory properties with the aspect `sys:incomplete`. This is done so that you can create items that have mandatory properties even if the value of the property is not known at the time of content creation, while still indicating that the property is required (eventually). Mandatory properties will have a `*` next to them in the UI.<br><br>`false` = it is optional and this is the default if this element is not specified.<br><br>The `mandatory` element can also have a `boolean` attribute called `enforced`. If this is set to `true` then you cannot create a node without this property having a value.|<br><br>
|`multiple`|element (boolean)|`[0..1]`|`true` = this property can have a list of values.<br><br>`false` = only one value can be entered and this is the default if this element is not specified.|
|`default`|element (any)|`[0..1`]|Default value for this property if the user does not specify any value. The UI input field will be pre-populated with this value.|
|`index`|element|`[0..1]`|Solr/Lucene index configuration. The indexing behavior for each property can be configured. If we don't configure any indexing behavior, then the default configuration is:<br><br>`<index enabled="true">`<br><br>&nbsp;&nbsp;`<atomic>true</atomic>`<br><br>&nbsp;&nbsp;`<stored>false</stored>`<br><br>&nbsp;&nbsp;`<tokenised>true</tokenised>`<br><br>`</index>`<br><br>Explanation of default index configuration:<br><br>`enabled="true"`: index the value of the property. Setting this to `false` means that the property is not indexed at all and is not part of the index.<br><br> `<atomic>true</atomic>`: atomic is not used when Content Services uses Solr for search. The default value is there to allow the continued use of the built in Lucene indexing engine when customers don't want to, or cannot, switch to Solr. With Solr the index is eventually up-to-date with the database (properties/metadata are stored in the database).<br><br>`<stored>false</stored>`: the property value is not stored in the index. This property is not used with Solr either, all fields are store in the new cached content store on the Solr side.<br><br>`<tokenised>true</tokenised>`: the property value is tokenized when it's indexed, so if the value is "Company Confidential" it will be tokenized into two strings that will be indexed separately, which might not always be what you want. You can also use `false`, which will just tokenize the value as one item. Further on, it also possible to set it to `both`, which means that "Company Confidential", "Company", and "Confidential" will be in the index. The tokenizer is determined by the property type in the data dictionary. This is locale sensitive as supported by the data dictionary, so you could switch to tokenize all your content in for example German. You cannot mix for example German and English tokenization.<br><br>There is also another sub-element that can be specified for the `index` element. It is called `facetable` and controls the faceting behavior in Solr as follows:<br><br>`<facetable>true</facetable>`: property is set up properly in Solr for faceting and is really fast, ordered, and sorted.<br><br>`<facetable>false</facetable>`: property is not facetable, that is, you cannot create a facet from this property. In some cases it makes no sense to make a property facetable, for example if it is a unique property. Note that setting facetable to false will not save resources.<br><br>**Unspecified as above (default):** faceting works but not as fast and efficient as when this element is explicitly specified and set to `true`.|
|`index`|element|`[0..1]`|Solr/Lucene index configuration. The indexing behavior for each property can be configured. If we don't configure any indexing behavior, then the default configuration is:<br><br>`<index enabled="true">`<br><br>&nbsp;&nbsp;`<atomic>true</atomic>`<br><br>&nbsp;&nbsp;`<stored>false</stored>`<br><br>&nbsp;&nbsp;`<tokenised>true</tokenised>`<br><br>`</index>`<br><br>Explanation of default index configuration:<br><br>`enabled="true"`: index the value of the property. Setting this to `false` means that the property is not indexed at all and is not part of the index.<br><br> `<atomic>true</atomic>`: atomic is not used when Content Services uses Solr for search. The default value is there to allow the continued use of the built in Lucene indexing engine when customers don't want to, or cannot, switch to Solr. With Solr the index is eventually up-to-date with the database (properties/metadata are stored in the database).<br><br>`<stored>false</stored>`: the property value is not stored in the index. This property is not used with Solr either, all fields are store in the new cached content store on the Solr side.<br><br>`<tokenised>true</tokenised>`: the property value is tokenized when it's indexed, so if the value is "Company Confidential" it will be tokenized into two strings that will be indexed separately, which might not always be what you want. You can also use `false`, which will just tokenize the value as one item. Further on, it also possible to set it to `both`, which means that "Company Confidential", "Company", and "Confidential" will be in the index. The tokenizer is determined by the property type in the data dictionary. This is locale sensitive as supported by the data dictionary, so you could switch to tokenize all your content in for example German. You cannot mix for example German and English tokenization. <br><br>_Tokenized searches are case-insensitive, while un-tokenized searches are case-sensitive._<br><br>There is also another sub-element that can be specified for the `index` element. It is called `facetable` and controls the faceting behavior in Solr as follows:<br><br>`<facetable>true</facetable>`: property is set up properly in Solr for faceting and is really fast, ordered, and sorted.<br><br>`<facetable>false</facetable>`: property is not facetable, that is, you cannot create a facet from this property. In some cases it makes no sense to make a property facetable, for example if it is a unique property. Note that setting facetable to false will not save resources.<br><br>**Unspecified as above (default):** faceting works but not as fast and efficient as when this element is explicitly specified and set to `true`.|
|`constraints`|element|`[0..1]`|Container for property constraints.|

The last thing that is defined in the model are the `aspects`. The definition of an aspect does not differ much from a
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -429,7 +429,7 @@ The following table describes all the parameters that can be used when defining
|`mandatory`|element (boolean)|`[0..1`]|`true` = when a property is set as mandatory it tells Content Services that the property is required. By default, this is not enforced. Instead, Content Services marks content items with empty mandatory properties with the aspect `sys:incomplete`. This is done so that you can create items that have mandatory properties even if the value of the property is not known at the time of content creation, while still indicating that the property is required (eventually). Mandatory properties will have a `*` next to them in the UI.<br><br>`false` = it is optional and this is the default if this element is not specified.<br><br>The `mandatory` element can also have a `boolean` attribute called `enforced`. If this is set to `true` then you cannot create a node without this property having a value.|<br><br>
|`multiple`|element (boolean)|`[0..1]`|`true` = this property can have a list of values.<br><br>`false` = only one value can be entered and this is the default if this element is not specified.|
|`default`|element (any)|`[0..1`]|Default value for this property if the user does not specify any value. The UI input field will be pre-populated with this value.|
|`index`|element|`[0..1]`|Solr/Lucene index configuration. The indexing behavior for each property can be configured. If we don't configure any indexing behavior, then the default configuration is:<br><br>`<index enabled="true">`<br><br>&nbsp;&nbsp;`<atomic>true</atomic>`<br><br>&nbsp;&nbsp;`<stored>false</stored>`<br><br>&nbsp;&nbsp;`<tokenised>true</tokenised>`<br><br>`</index>`<br><br>Explanation of default index configuration:<br><br>`enabled="true"`: index the value of the property. Setting this to `false` means that the property is not indexed at all and is not part of the index.<br><br> `<atomic>true</atomic>`: atomic is not used when Content Services uses Solr for search. The default value is there to allow the continued use of the built in Lucene indexing engine when customers don't want to, or cannot, switch to Solr. With Solr the index is eventually up-to-date with the database (properties/metadata are stored in the database).<br><br>`<stored>false</stored>`: the property value is not stored in the index. This property is not used with Solr either, all fields are store in the new cached content store on the Solr side.<br><br>`<tokenised>true</tokenised>`: the property value is tokenized when it's indexed, so if the value is "Company Confidential" it will be tokenized into two strings that will be indexed separately, which might not always be what you want. You can also use `false`, which will just tokenize the value as one item. Further on, it also possible to set it to `both`, which means that "Company Confidential", "Company", and "Confidential" will be in the index. The tokenizer is determined by the property type in the data dictionary. This is locale sensitive as supported by the data dictionary, so you could switch to tokenize all your content in for example German. You cannot mix for example German and English tokenization.<br><br>There is also another sub-element that can be specified for the `index` element. It is called `facetable` and controls the faceting behavior in Solr as follows:<br><br>`<facetable>true</facetable>`: property is set up properly in Solr for faceting and is really fast, ordered, and sorted.<br><br>`<facetable>false</facetable>`: property is not facetable, that is, you cannot create a facet from this property. In some cases it makes no sense to make a property facetable, for example if it is a unique property. Note that setting facetable to false will not save resources.<br><br>**Unspecified as above (default):** faceting works but not as fast and efficient as when this element is explicitly specified and set to `true`.|
|`index`|element|`[0..1]`|Solr/Lucene index configuration. The indexing behavior for each property can be configured. If we don't configure any indexing behavior, then the default configuration is:<br><br>`<index enabled="true">`<br><br>&nbsp;&nbsp;`<atomic>true</atomic>`<br><br>&nbsp;&nbsp;`<stored>false</stored>`<br><br>&nbsp;&nbsp;`<tokenised>true</tokenised>`<br><br>`</index>`<br><br>Explanation of default index configuration:<br><br>`enabled="true"`: index the value of the property. Setting this to `false` means that the property is not indexed at all and is not part of the index.<br><br> `<atomic>true</atomic>`: atomic is not used when Content Services uses Solr for search. The default value is there to allow the continued use of the built in Lucene indexing engine when customers don't want to, or cannot, switch to Solr. With Solr the index is eventually up-to-date with the database (properties/metadata are stored in the database).<br><br>`<stored>false</stored>`: the property value is not stored in the index. This property is not used with Solr either, all fields are store in the new cached content store on the Solr side.<br><br>`<tokenised>true</tokenised>`: the property value is tokenized when it's indexed, so if the value is "Company Confidential" it will be tokenized into two strings that will be indexed separately, which might not always be what you want. You can also use `false`, which will just tokenize the value as one item. Further on, it also possible to set it to `both`, which means that "Company Confidential", "Company", and "Confidential" will be in the index. The tokenizer is determined by the property type in the data dictionary. This is locale sensitive as supported by the data dictionary, so you could switch to tokenize all your content in for example German. You cannot mix for example German and English tokenization. <br><br>_Tokenized searches are case-insensitive, while un-tokenized searches are case-sensitive._<br><br>There is also another sub-element that can be specified for the `index` element. It is called `facetable` and controls the faceting behavior in Solr as follows:<br><br>`<facetable>true</facetable>`: property is set up properly in Solr for faceting and is really fast, ordered, and sorted.<br><br>`<facetable>false</facetable>`: property is not facetable, that is, you cannot create a facet from this property. In some cases it makes no sense to make a property facetable, for example if it is a unique property. Note that setting facetable to false will not save resources.<br><br>**Unspecified as above (default):** faceting works but not as fast and efficient as when this element is explicitly specified and set to `true`.|
|`constraints`|element|`[0..1]`|Container for property constraints.|

The last thing that is defined in the model are the `aspects`. The definition of an aspect does not differ much from a
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -429,7 +429,7 @@ The following table describes all the parameters that can be used when defining
|`mandatory`|element (boolean)|`[0..1`]|`true` = when a property is set as mandatory it tells Content Services that the property is required. By default, this is not enforced. Instead, Content Services marks content items with empty mandatory properties with the aspect `sys:incomplete`. This is done so that you can create items that have mandatory properties even if the value of the property is not known at the time of content creation, while still indicating that the property is required (eventually). Mandatory properties will have a `*` next to them in the UI.<br><br>`false` = it is optional and this is the default if this element is not specified.<br><br>The `mandatory` element can also have a `boolean` attribute called `enforced`. If this is set to `true` then you cannot create a node without this property having a value.|<br><br>
|`multiple`|element (boolean)|`[0..1]`|`true` = this property can have a list of values.<br><br>`false` = only one value can be entered and this is the default if this element is not specified.|
|`default`|element (any)|`[0..1`]|Default value for this property if the user does not specify any value. The UI input field will be pre-populated with this value.|
|`index`|element|`[0..1]`|Solr/Lucene index configuration. The indexing behavior for each property can be configured. If we don't configure any indexing behavior, then the default configuration is:<br><br>`<index enabled="true">`<br><br>&nbsp;&nbsp;`<atomic>true</atomic>`<br><br>&nbsp;&nbsp;`<stored>false</stored>`<br><br>&nbsp;&nbsp;`<tokenised>true</tokenised>`<br><br>`</index>`<br><br>Explanation of default index configuration:<br><br>`enabled="true"`: index the value of the property. Setting this to `false` means that the property is not indexed at all and is not part of the index.<br><br> `<atomic>true</atomic>`: atomic is not used when Content Services uses Solr for search. The default value is there to allow the continued use of the built in Lucene indexing engine when customers don't want to, or cannot, switch to Solr. With Solr the index is eventually up-to-date with the database (properties/metadata are stored in the database).<br><br>`<stored>false</stored>`: the property value is not stored in the index. This property is not used with Solr either, all fields are store in the new cached content store on the Solr side.<br><br>`<tokenised>true</tokenised>`: the property value is tokenized when it's indexed, so if the value is "Company Confidential" it will be tokenized into two strings that will be indexed separately, which might not always be what you want. You can also use `false`, which will just tokenize the value as one item. Further on, it also possible to set it to `both`, which means that "Company Confidential", "Company", and "Confidential" will be in the index. The tokenizer is determined by the property type in the data dictionary. This is locale sensitive as supported by the data dictionary, so you could switch to tokenize all your content in for example German. You cannot mix for example German and English tokenization.<br><br>There is also another sub-element that can be specified for the `index` element. It is called `facetable` and controls the faceting behavior in Solr as follows:<br><br>`<facetable>true</facetable>`: property is set up properly in Solr for faceting and is really fast, ordered, and sorted.<br><br>`<facetable>false</facetable>`: property is not facetable, that is, you cannot create a facet from this property. In some cases it makes no sense to make a property facetable, for example if it is a unique property. Note that setting facetable to false will not save resources.<br><br>**Unspecified as above (default):** faceting works but not as fast and efficient as when this element is explicitly specified and set to `true`.|
|`index`|element|`[0..1]`|Solr/Lucene index configuration. The indexing behavior for each property can be configured. If we don't configure any indexing behavior, then the default configuration is:<br><br>`<index enabled="true">`<br><br>&nbsp;&nbsp;`<atomic>true</atomic>`<br><br>&nbsp;&nbsp;`<stored>false</stored>`<br><br>&nbsp;&nbsp;`<tokenised>true</tokenised>`<br><br>`</index>`<br><br>Explanation of default index configuration:<br><br>`enabled="true"`: index the value of the property. Setting this to `false` means that the property is not indexed at all and is not part of the index.<br><br> `<atomic>true</atomic>`: atomic is not used when Content Services uses Solr for search. The default value is there to allow the continued use of the built in Lucene indexing engine when customers don't want to, or cannot, switch to Solr. With Solr the index is eventually up-to-date with the database (properties/metadata are stored in the database).<br><br>`<stored>false</stored>`: the property value is not stored in the index. This property is not used with Solr either, all fields are store in the new cached content store on the Solr side.<br><br>`<tokenised>true</tokenised>`: the property value is tokenized when it's indexed, so if the value is "Company Confidential" it will be tokenized into two strings that will be indexed separately, which might not always be what you want. You can also use `false`, which will just tokenize the value as one item. Further on, it also possible to set it to `both`, which means that "Company Confidential", "Company", and "Confidential" will be in the index. The tokenizer is determined by the property type in the data dictionary. This is locale sensitive as supported by the data dictionary, so you could switch to tokenize all your content in for example German. You cannot mix for example German and English tokenization. <br><br>_Tokenized searches are case-insensitive, while un-tokenized searches are case-sensitive._<br><br>There is also another sub-element that can be specified for the `index` element. It is called `facetable` and controls the faceting behavior in Solr as follows:<br><br>`<facetable>true</facetable>`: property is set up properly in Solr for faceting and is really fast, ordered, and sorted.<br><br>`<facetable>false</facetable>`: property is not facetable, that is, you cannot create a facet from this property. In some cases it makes no sense to make a property facetable, for example if it is a unique property. Note that setting facetable to false will not save resources.<br><br>**Unspecified as above (default):** faceting works but not as fast and efficient as when this element is explicitly specified and set to `true`.|
|`constraints`|element|`[0..1]`|Container for property constraints.|

The last thing that is defined in the model are the `aspects`. The definition of an aspect does not differ much from a
Expand Down