[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Allow easier regexp substring searching on enum fields
From: |
William M. (Mike) Miller |
Subject: |
Re: Allow easier regexp substring searching on enum fields |
Date: |
Tue, 28 Feb 2006 16:21:23 -0500 |
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
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Allow easier regexp substring searching on enum fields,
William M. (Mike) Miller <=
- Next by Date:
help
- Next by thread:
help
- Index(es):