Dear team,
Description
When exporting data from a cube in Planning Analytics Workspace (PAW), the Cube Data Export dialog provides comparison operators for string-based values that are primarily associated with numeric comparisons.
Lexicographical comparisons such as Greater than, Less than, and Between can technically be valid for string values. For example, values such as ABC1, ABC2, ABC3, etc. can be compared lexicographically.
However, the current Cube Data Export UI does not distinguish between numeric comparisons and lexicographical string comparisons. In addition, string-specific filtering options that are already available in other PAW components, such as the Set Editor, are not available in the Cube Data Export dialog.
This can make the filtering behavior difficult for users to understand and limits the available filtering options for string-based data.
Current Behavior
For string values, the Cube Data Export dialog provides operators such as:
Greater than
Greater than or equal
Less than
Less than or equal
Between
These operators perform lexicographical comparisons.
For example, when filtering the following values:
ABC1ABC2ABC3ABC4ABC5ABC6ABC7
using:
Greater than ABC3
the result is:
ABC4ABC5ABC6ABC7
This behavior is technically valid, but the UI does not make it clear that the comparison is based on lexicographical ordering.
At the same time, common string filtering operations such as:
Contains
Starts with
Ends with
are not available in the Cube Data Export dialog, although similar filtering capabilities are already available when working with dimension elements in the Set Editor.
Expected Behavior
The Cube Data Export dialog should provide filtering operators appropriate for string values while preserving the existing lexicographical comparison functionality.
For string-based values, PAW should provide string-specific operators such as:
Equal to
Not equal to
Contains
Starts with
Ends with
Lexicographical comparison operators may remain available for string values where they are technically meaningful:
Greater than
Greater than or equal
Less than
Less than or equal
Between
However, the UI should clearly distinguish these operators from numeric comparisons or otherwise indicate that they perform lexicographical string comparisons.
For example, the filtering options could be grouped into:
String matching
Equal to
Not equal to
Contains
Starts with
Ends with
Lexicographical comparison
Greater than
Greater than or equal
Less than
Less than or equal
Between
Numeric fields should continue to provide the appropriate numeric comparison operators.
Consistency with Existing PAW Functionality
The proposed enhancement would also improve consistency between Cube Data Export and the Set Editor.
The Set Editor already provides users with string-oriented filtering capabilities when working with dimension elements. Providing comparable string filtering functionality in Cube Data Export would allow users to apply familiar filtering concepts across PAW components.
This does not require removing the existing lexicographical comparison functionality. Instead, it would make the distinction between string matching and lexicographical comparison explicit while extending the available filtering capabilities.
Business Value
Clear and type-appropriate filtering options would:
make Cube Data Export easier to understand and use,
reduce confusion about how string values are evaluated,
provide commonly required string filtering operations,
improve consistency with the Set Editor,
preserve existing lexicographical filtering use cases, and
provide a more intuitive user experience when exporting cube data.
Example
Given the following Product values:
A100A150A200B100B200
Users should be able to select:
Starts with → A
to retrieve:
A100A150A200
or:
Contains → 15
to retrieve:
A150
At the same time, users who explicitly require lexicographical filtering should still be able to select:
Greater than → A150
which would return values according to lexicographical ordering.
This approach would preserve the current functionality while making the filtering semantics clearer and providing additional string-specific filtering capabilities.
With best regards,
Vitalij
+1
A clarification based on the discussion with IBM Support:
We understand that lexicographical comparisons for string values are technically valid and that there are legitimate use cases for operators such as Greater than, Less than and Between.
Our suggestion is therefore not to remove these operators.
Instead, we propose making the distinction between string matching and lexicographical comparison explicit in the Cube Data Export UI and additionally providing the string-specific operators already familiar from the Set Editor, such as Contains, Starts with and Ends with.
This would preserve the existing functionality while making the filtering behavior more transparent and providing users with a broader and more intuitive set of options for string-based data.