Re: Expected behaviour for absent fields

[Mel Hatzis]

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" & <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
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