From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21832 invoked from network); 29 Mar 2004 23:43:10 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 29 Mar 2004 23:43:10 -0000 Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B86Nx-0003au-Dh for listarch-gnats-devel@sources.redhat.com; Mon, 29 Mar 2004 18:41:41 -0500 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B86Nh-0003aR-86 for help-gnats@gnu.org; Mon, 29 Mar 2004 18:41:25 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B86NB-0003OX-DN for help-gnats@gnu.org; Mon, 29 Mar 2004 18:41:24 -0500 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.30) id 1B86NB-0003O7-0i for help-gnats@gnu.org; Mon, 29 Mar 2004 18:40:53 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i2TNeol72060; Mon, 29 Mar 2004 15:40:50 -0800 (PST) (envelope-from hatzis@juniper.net) Received: from juniper.net (snowy.juniper.net [172.17.13.16]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i2TNejJ50398; Mon, 29 Mar 2004 15:40:45 -0800 (PST) (envelope-from hatzis@juniper.net) Message-ID: <4068B3FD.4090307@juniper.net> Date: Tue, 30 Mar 2004 03:11:00 -0000 From: Mel Hatzis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Ashley References: <20040329121031.491a0f4e.adrian.ashley@broadcom.com> In-Reply-To: <20040329121031.491a0f4e.adrian.ashley@broadcom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: help-gnats@gnu.org Subject: Re: Expected behaviour for absent fields X-BeenThere: help-gnats@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: General discussion about GNU GNATS List-Archive: List-Post: List-Help: List-Subscribe: , Sender: help-gnats-bounces+listarch-gnats-devel=sources.redhat.com@gnu.org Errors-To: help-gnats-bounces+listarch-gnats-devel=sources.redhat.com@gnu.org X-SW-Source: 2004-q1/txt/msg00185.txt.bz2 Hi Adrian, ... Adrian Ashley wrote: > I have a GNATS-4 installation with a number of additional fields in the > database. In this example, "fix-rel" is one of these - defined thusly: > > field "fix-rel" { > description "fix release" > text matching { "^$" "^(VE|IP)(_[0-9]\+)\+$" } > textsearch > } > > i.e. the empty string or specially formed tag names are allowed. > The other thing to note is that this field isn't included in the > initial-entry fields. It's inclusion in the 'index' fields is also relevant here. Based on your observed behaviour, I assume that it's also not defined as an "index" field. [ The reason this is relevant is that all fields defined in the "index" are assigned an empty value in the index, when a PR is added to the index. Subsequent GNATS queries will use the index to determine the field value, and therefore a NULL value wouldn't be returned. ] > > One of our users reports a peculiarity: a query like this: > > $ query-pr --expr \ > 'category=="foo" & & (fix-rel != "VE_6")' > > doesn't match PRs for which this field is not yet set - and there > doesn't seem to be any way for him to work around this. > > Looking at query.c:fieldCompare() and field.c:get_field_value(), it > seems that the latter returns NULL for a field which is not yet set, and > the former concludes that if either of its field values are NULL, the > comparison must be false. Your observation is correct. > > It looks like the right fix is in fieldCompare(), to cope with NULL > meaning empty. Has anyone been near this code and could advise whether > I'll be breaking something else by doing this? Or is the problem that > my database has fields that can be unset - am I breaking some rule? A NULL value typically means "undefined" and, IMO, GNATS is doing the right thing. Generally speaking, a query against an "undefined" value should never match...there are other examples of such behaviour (e.g Oracle) and I think this might also be described in the SQL standard. One way around the problem you've observed is to assign a default value for the "fix-rel" field, however, this is currently unsupported for "text" fields, unfortunately. Given the relatively small size of the fix-rel values, I suggest you might want to try adding the field to the "index" as a work-around. This should address the query problem you have and won't otherwise be much of an impact on your existing configuration. Hopefully, someone will find the time to add support for "default" values for "text" fields for the next release. This would be a better solution, IMO. -- Mel Hatzis _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://mail.gnu.org/mailman/listinfo/help-gnats