Handling multi-select attributes in an application

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.

The Dgraph process behaves differently for the two types of multi-select managed attributes:

Avoiding dead-end query results

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.

Assume the user’s current query contains all three values. The user’s current navigation state would represent the query:
"Return all records tagged with (1 or 2) and 3"
If the user then removes one of the values from Attribute Alpha, a dead end could be reached. For example, if the user removes value 1, the new query becomes:
"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.

Performance impact for multi-select managed attributes

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 for multi-or refinements

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.

When the user requests Chinese or Japanese as refinements during navigation, the resulting record list includes all 6 records, out of which 2 have only Chinese attribute, 3 have only Japanese attribute, and 1 has both:
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).