Comment 3 for bug 1511828

I wonder if the following is also off, sorting the best hold selection sorting options by value using cmp, which is for string comparison. Since currently the number of options is less than 10, it acts correctly, but I wonder if it would break if two more sort options are added. Otherwise I don't think that the opportunistic capture is effected, since the sorting is done in the DB.

    ) || {
        pprox => 1, hprox => 8, aprox => 2, priority => 3,
        cut => 4, depth => 5, htime => 7, rtime => 6
    };

    # Return only the keys of our hash, sorted by value,
    # keys for null values omitted.
    return [
        grep { defined $row->{$_} } (
            sort {$row->{$a} cmp $row->{$b}} keys %$row
        )
    ];

Yep, I think that could be a problem in the future.
Here is a little test.

----
#!/usr/bin/perl

use Data::Dumper;

sub get_hold_sort_order {
my $row =
{
        pprox => 1, hprox => 8, aprox => 2, priority => 3,
        cut => 4, depth => 5, htime => 7, rtime => 6,
        taco => 9, foo => 10, bar => 11, baz => 12
};

    # Return only the keys of our hash, sorted by value,
    # keys for null values omitted.
    return [
        grep { defined $row->{$_} } (
            sort {$row->{$a} cmp $row->{$b}} keys %$row
        )
    ];
}

print Dumper(get_hold_sort_order());
-----

Output shows that 10,11,12 are sorted as the 2nd-4th sort options.
$VAR1 = [
          'pprox',
          'foo',
          'bar',
          'baz',
          'aprox',
          'priority',
          'cut',
          'depth',
          'rtime',
          'htime',
          'hprox',
          'taco'
        ];

}

using numeric comparison <=>

$VAR1 = [
          'pprox',
          'aprox',
          'priority',
          'cut',
          'depth',
          'rtime',
          'htime',
          'hprox',
          'taco',
          'foo',
          'bar',
          'baz'
        ];