Github user kkhatua commented on a diff in the pull request:
https://github.com/apache/drill/pull/987#discussion_r148126237
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/server/rest/profile/OperatorWrapper.java
---
@@ -76,12 +77,14 @@ public String getId() {
public String getContent() {
TableBuilder builder = new TableBuilder(OPERATOR_COLUMNS,
OPERATOR_COLUMNS_TOOLTIP, true);
+ Map<String, String> attributeMap = new HashMap<String, String>();
//Reusing for different fragments
for (ImmutablePair<ImmutablePair<OperatorProfile, Integer>, String> ip
: opsAndHosts) {
int minor = ip.getLeft().getRight();
OperatorProfile op = ip.getLeft().getLeft();
+ attributeMap.put("data-order", String.valueOf(minor)); //Overwrite
values from previous fragments
--- End diff --
You are correct that the values must be zero padded. However, the padding
by default is only up till achieving a width of two digits. The sequencing
didn't get messed up as long as the number of minor fragments for each major
fragment was less than 100.
For greater than 100, the sequencing broke the way you described it.
So, until this fix, you'll get the minor fragment ordered as:
01-01-XX ..... 01-10-XX, 01-100-XX, ....
instead of
01-01-XX ..... 01-10-XX, 01-11-XX, .... 01-10-XX, 01-11-XX, .... 01-100-XX,
01-101-XX
What we are doing is injecting the <td> element with an attribute that
carries the actual numeric value. The dataTable library will discover and sort
the elements of a column by the value of this attribute instead of the value
that the element encapsulates.
---