The behavior of multi-select attributes may require changes in the UI.
The fact that an attribute is tagged as multi-select should be transparent to the application developer. There is no special development required to enable multi-select attributes, and there are no query parameters that are specific to multi-select attributes.
However, the semantics of how the Dgraph process of the Oracle Endeca Server interprets navigation queries and returns available refinements changes once an attribute is tagged as multi-select. After tagging an attribute as multi-select, the Dgraph allows multiple attribute values from the same attribute to be added to the navigation state.
Be careful when rendering the selected managed attribute values of multi-or managed attributes. It is possible to create an interface that might result in dead ends when removing selected attribute values.
Consider this example: Managed attribute Alpha has been flagged as multi-or, and contains values 1 and 2. Attribute Beta contains value 3.
"Return all records tagged with (1 or 2) and 3"
"Return all records tagged with 2 and 3"
This could result in a dead end if no records are tagged with both value 2 and 3.
Due to this behavior, it is recommended that the UI be designed so that the user must be forced to remove all values from a multi-or managed attribute when making changes to the list of selected attribute values.
Tagging an attribute as multi-select does not affect performance. However, when making decisions about when to tag an attribute as multi-select, keep the following in mind: Users will take longer to refine the list of results, because each selection from a multi-select managed attribute still allows for further refinements within that attribute. Also, refinements for multi-or attribute are more expensive.
Refinement counts on a standard refinement that is multi-or indicate how many records in the result set will be tagged with the refinement if you select it. When there are no selections made yet, the refinement count equals the total number of records in the result set if that refinement were selected. However, for subsequent refinements, the refinement count may differ from the total results set.
Consider the following example which illustrates this use case. A cuisine refinement is configured as multi-or. In the data set, there are 2 records that have assignments only to a Chinese attribute, and 3 records that have assignments only to a Japanese attribute. There is also 1 record that has assignments on both of these attributes.
Records | Assignment on a Chinese attribute | Assignment on a Japanese attribute |
---|---|---|
1 | x | |
2 | x | |
3 | x | x |
4 | x | |
5 | x | |
6 | x |
If the user first selects only Chinese, the navigation state shows that there is one remaining follow-on refinement (Japanese) with the refinement count of 4 records (3 with only Japanese assignment on a attribute and 1that has both Chinese and Japanese attribute assignments on them). When the user navigates on that refinement, the resulting record list includes all 6 records. This illustrates that a record count for a Japanese refinement shows the number of records (4) tagged with that refinement, within the entire record set (6).