[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Expected behaviour for absent fields

From: Mel Hatzis
Subject: Re: Expected behaviour for absent fields
Date: Mon, 29 Mar 2004 15:40:45 -0800
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040310

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]\+)\+$" }

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" & <more clauses> & (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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]