Best answer by takashi
View original
Best answer by takashi
View originalHi!
Before having the list build, split your "lbl" (like lbl_num and lbl_alpha) and then sort list by lbl_num. Like that you will have 3 and 15 as range.
Wich places 15 before 7. This is normal behaviour.
Before building the list and consequentially before the listrange extractor ,i would use a sorter and sort on both components. If they are not available separate, you must first create sorting fields by splitting them.
If not possible before building the list, you still must split the listattribute, wich forces u to explode the list...
So i would definitely do it before listbuilding iff poss.
The ListRangeExtractor cannot be used in this case.
"If some values are numeric and some are not, the minimum and maximum values extracted may not be useful." -- Help of the ListRangeExtractor
Expanding @markireland's suggestion, if the resulting minimum value should be "3A", this workflow is available.
However, if the "list{}.lbl" has been created in the preceding data flow in the workspace, I would consider firstly whether @francis_m and @gio's suggestion (sort before list building) can be applied.
Takashi
Thanks for pointing out for me that the ListRangeExtractor is either numerical OR alphabetical, not both in combination.
As my need was to maintain the alphanumeric structure I ended up with much of Takashi's structure. The numeric and alphabetical part of lbl was available, so I created a custom transformer to do the trick, with a ListSorter on the numeric part, and then two ListIndexers to extract the correct max and min values. Thanks to the rest of you for the suggestions to look for the original numerical and character parts of "lbl".
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.