We need to have similar capability to define alternative sorting column for column in data set - eg. sorting name by corresponding code for dimension.
Basically have the same ability in data sets to define sort column for attribute column as we can define "sort order column" property for logical column in BMM in metadata/semantic model.
This is really very much missing for "self-service" capability , switching to metadata/semantic model is not an option.
The other (but not that prefered option/solution, but still kind of acceptable solution) for that requirement would be following solution:
Allow in DV workbook in vizualization within "Sort By" --> Custom menu option, where you can define custom sorting, the option to sort attribute column by another column (but again attribute column, not a measure column - which is current option).
To fulfill this requrment is really important for our DV users, so I hope, this Idea will be evaluted (and put into plan for implementation).
The headache here will always be grain, and we must define how to resolve conflicts (which some people will like and some will not). i.e., the scenario works well when there is a 1:1 relationship between the attribute and the sort key; with measures, the aggregation method ensures that. With attribute to attribute, we might have 1:n scenarios, which will cause at least two key issues:
Overall, it is a valid idea/need, but not as simple as measures. We are currently working on some new Workbook query capabilities, which might help customers achieve these types of use cases (although not as straightforward as 'sort A by B').
Looking at other products (our two friends from the Seattle area), both seem to have the same limitation for what I assume to be exactly the same reasons. I have also seen some funky solutions, such as converting your attribute to decimal ASCII codes (and then you need to make sure you normalize the string lengths), but I would not recommend this as a reasonable route to a user.
Gabby.
@Gabby Rubin-Oracle another idea would be to allow one to hide columns in the display. At least this is how we achieved this in Classis Analyses. We would set sort on Column A and then hide it in the table/pivot.
@Dorothy Joseph-Oracle This is actually planned.
Awesome. Thank you @Gabby Rubin-Oracle - I've added my vote to it now.
@Gabby Rubin-Oracle Gabby, thanks for the explanation. But I don't think it is so complicated. Majority of use cases are following :
And this is quite obvious requirement and should not be (I guess) that complicated to implement it in similar way as it is in "classics" - as I alredy pointed :
Either in data set definitions (if I am not using semantic model in RPD, where I can easily define the same) - by -implementing "sort by" property for some columns - this is for me more systematic solution since all workbook using data set could leverage this
Or directly in DV workbook allowing to define sorting by attribute column.
But anyway whatever form of implementation is better than current status.
Thanks
Michal
@Michal Zima I know how you will use it, but we must consider other possible scenarios and outcomes. At the end of the day, we need to ensure the outcome is clear even when the use case is not what we expect it to be. The alternative columns must participate in the query in some way, and as such, they will impact the results, although not seen. In the basic 1:1 scenario, all will be well, and that might be 95% of the usage.
The two approaches that are currently explored are:
We will update on both as it progresses.
Gabby.
