| 2015-06-12 20:28:28 |
Jason Boyer |
description |
All versions with evergreen.lpad_number_substrings, other versions N/A (Note: The version of this function in Eg 2.7 is different than the version in master, but I put the current version into my test db and it doesn't fix this problem.)
The evergreen.lpad_number_substrings function is used in multiple places to create sortkeys for various labels, but if the label contains smaller substrings of numbers that are matched within larger strings of numbers, the padding will be off. (This is harder to explain in English than it is to show...)
As an example, this monograph part label '2015 01 (Jan)' will call this function with a pad of '0' and a length of 10, which should result in '0000002015 0000000001 (Jan)' (I'm ignoring the naco_normalize step here, it's not relevant to the issue) but because the 01 is also present in 2015, the result is '000000200000000015 0000000001 (Jan)' The fix is to make the s/// at the bottom of the function more picky about it's matches. I've found out what it needs to be, now I need to learn about these tests I keep hearing so much about. :)
If you are impatient and want to help test before I have time to figure the pgtap testing part out, this is the function that works for me, note the s/(^|\D)$1($|\D)/$1$padded$2/sg :
CREATE OR REPLACE FUNCTION evergreen.lpad_number_substrings(text, text, integer)
RETURNS text
LANGUAGE plperlu
AS $function$
my $string = shift;
my $pad = shift;
my $len = shift;
my $find = $len - 1;
while ($string =~ /(?:^|\D)(\d{1,$find})(?:$|\D)/) {
my $padded = $1;
$padded = $pad x ($len - length($padded)) . $padded;
$string =~ s/(^|\D)$1($|\D)/$1$padded$2/sg;
}
return $string;
$function$
This should be an easy test to write, I'm hoping I can get to it soon. |
All versions with evergreen.lpad_number_substrings, other versions N/A (Note: The version of this function in Eg 2.7 is different than the version in master, but I put the current version into my test db and it doesn't fix this problem.)
The evergreen.lpad_number_substrings function is used in multiple places to create sortkeys for various labels, but if the label contains smaller substrings of numbers that are matched within larger strings of numbers, the padding will be off. (This is harder to explain in English than it is to show...)
As an example, this monograph part label '2015 01 (Jan)' will call this function with a pad of '0' and a length of 10, which should result in '0000002015 0000000001 (Jan)' (I'm ignoring the naco_normalize step here, it's not relevant to the issue) but because the 01 is also present in 2015, the result is '000000200000000015 0000000001 (Jan)' The fix is to make the s/// at the bottom of the function (circa 2.7) more picky about its matches. I've found out what it needs to be, now I need to learn about these tests I keep hearing so much about. :)
If you are impatient and want to help test before I have time to figure the pgtap testing part out, this is the function that works for me, note the s/(^|\D)$1($|\D)/$1$padded$2/sg near the bottom:
CREATE OR REPLACE FUNCTION evergreen.lpad_number_substrings(text, text, integer)
RETURNS text
LANGUAGE plperlu
AS $function$
my $string = shift;
my $pad = shift;
my $len = shift;
my $find = $len - 1;
while ($string =~ /(?:^|\D)(\d{1,$find})(?:$|\D)/) {
my $padded = $1;
$padded = $pad x ($len - length($padded)) . $padded;
$string =~ s/(^|\D)$1($|\D)/$1$padded$2/sg;
}
return $string;
$function$
This should be an easy test to write, I'm hoping I can get to it soon. |
|
