Comment 23 for bug 1655158

Mike,

To be specific, the join/map/grep expression creates a SQL expression that looks like this:

....
JOIN (SELECT id as id FROM actor.usr u WHERE RIGHT('0'|| CAST( DATE_PART('day', dob ) AS text ), 2) ~ ? AND RIGHT('0'|| CAST( DATE_PART('month', dob ) AS text ), 2) ~ ?) AS search ON (search.id = users.id)
....

Here we have postgres doing string matching just like we do for the first_given_name and most of the other fields on the search form.

The javascript is responsible for forcing the day and month to come back to actor.pm with two digits.

I think I have addressed the concerns brought up by Jason in my comment #6. The concern about different date formats are currently accommodated because each component of the date is separate in the UI. This approach is ultimately better than any other UI that I could dream of. This allows the staff to search by a single component of the birth date without having to chose a specific date in the century using any "date picker" UI. "Keep it simple stupid" came to mind when developing this.

Here is the while loop that could replace the join/map/grep

    # while (($key, $value) = each (%$search)) {
        # if($$search{$key}{group} eq '4') {
            # my $tval = $key;
            # $tval =~ s/dob_//g;
            # my $right = "RIGHT('0'|| ";
            # my $end = ", 2)";
            # $end = $right = '' if lc $tval eq 'year';
            # $dob .= $right."CAST(DATE_PART('$tval', dob) AS text)$end ~ ? AND ";
        # }
    # }
    # # Trim the last " AND "
    # $dob = substr($dob,0,-4);

The while loop makes it more clear, but it's many more lines. It's nice that this logic can be in a single line! I think the code is cleaner "looking" without it. And the join/map/grep conforms to the rest of the code in that block.