Re: Allow easier regexp substring searching on enum fields

[William M. (Mike) Miller]

That's an interesting approach that hadn't occurred to me.  I see a couple of

possible issues with it, though.  First, it's susceptible to typographical

errors, where the user intended to type the whole value but made a mistake

that might possibly match part of another value.  Also, it treats all enum

and multienum fields the same, and some sites might want some to be

searched one way and some the other.

 

I still think the best approach would be to extend the gnatsd FTYPINFO

command to know about defaultSearchType and have gnatsweb use that

to determine whether to allow partial matches or not.  It looks pretty

straightfoward; I'll probably take a stab at that in a few days once I've

finished digging out from all the stuff that has prevented me from doing

any more GNATS-related stuff for the last couple of weeks.  Alternatively,

gnatsweb-site.pl could specify a list of field names for exact/inexact

searches, and gnatsweb.pl could query that list.

 

On 2/21/06, Jo A Wahle <address@hidden> wrote:

Yuck, that is a mess. I don't what to have to explain to users that they have to type
.*web.*
to find the categories somethingweb and webstuff and someotherwebcategory.
Does this do it? It works for some cases:

*** 2355,2367 ****
              # exact, not the substring type.
            # Hence, provide explicit anchoring for enums. This
            # still leaves the user the possibility of inserting
            # ".*" before and/or after regular _expression_ searches
            # on the advanced query page.
              if (fieldinfo($field, 'fieldtype') =~ "enum|multienum")
              {
!               $subexp = appendexpr ($subexp, '|', "$field~\"^$sval\$\"");
              }
              else
              {
                $subexp = appendexpr ($subexp, '|', "$field~\"$sval\"");
              }
--- 2357,2380 ----
              # exact, not the substring type.
            # Hence, provide explicit anchoring for enums. This
            # still leaves the user the possibility of inserting
            # ".*" before and/or after regular _expression_ searches
            # on the advanced query page.
+             # Yuck - who wants to type all that? Or explain it to users?
+             # Let's see if the value is one from the list - if not,
+             # allow substring match
+
              if (fieldinfo($field, 'fieldtype') =~ "enum|multienum")
              {
!               my $value_list=fieldinfo($field, 'values');
!               if (grep (/^$sval$/, @$value_list)) {
!                 $subexp = appendexpr ($subexp, '|', "$field~\"^$sval\$\"");
!               }
!               else
!               {
!                 $subexp = appendexpr ($subexp, '|', "$field~\"$sval\"");
!               }
              }
              else
              {
                $subexp = appendexpr ($subexp, '|', "$field~\"$sval\"");
              }

--
Jo Wahle, Software Engineer, Engineering Support, SAIC
(Science Applications International Corporation – www.saic.com)
Contractor to U.S. Geological Survey – EROS, Sioux Falls SD 57198
(Earth Resources Observation and Science – eros.usgs.gov)
Voice: 605-594-2514, FAX: 605-594-6940, E-mail: address@hidden
"Civilization exists by geological consent, subject to change without notice." --Will Durant

"William M. (Mike) Miller" <address@hidden >
Sent by: help-gnats-bounces+wahle=address@hidden

02/14/2006 09:58 AM

To	address@hidden
cc
Subject	Suggestions from a new GNATS/gnatsweb user

8. I wasn't sufficiently motivated to change this, but there's
  an annoying assumption regarding regular expressions for
  enumeration values in the following code:

     # Most (?) people expect queries on enums to be of the
     # exact, not the substring type.
     # Hence, provide explicit anchoring for enums. This
     # still leaves the user the possibility of inserting
     # ".*" before and/or after regular _expression_ searches
     # on the advanced query page.
     if (fieldinfo($field, 'fieldtype') =~ "enum|multienum")
     {
       $subexp = appendexpr ($subexp, '|', "$field~\"^$sval\$\"");
     }
     else
     {
       $subexp = appendexpr ($subexp, '|', "$field~\"$sval\"");
     }

  We aren't among the "most (?) people," apparently.  We have
  defined the enumeration for Priority to have values like
  "1 - showstopper", "2 - urgent", "3 - important", etc., so
  we'd like to use a regular _expression_ like "[12]" to match
  high-priority PRs and not have to type "[12].*".  We've set
  "query-default inexact-regexp" in dbconfig for the Priority
  field, but gnatsweb ignores it.  Either gnatsweb should
  honor that setting or it ought to be possible to override
  this assumption about enumerated fields by a setting in
  gnatsweb-site.pl.

-- 
William M. (Mike) Miller | Edison Design Group
address@hidden