Expected behaviour for absent fields

Expected behaviour for absent fields

[Adrian Ashley]

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.

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.

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?

Thanks,
Adrian Ashley
Broadcom Corp.




_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats

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


_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats

Re: Expected behaviour for absent fields

[Adrian Ashley]

Mel Hatzis wrote:

> 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.

That's true.

> [ 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. ]

Is this a Feature?  Perhaps the fact that a field is defined in the 
index ought to have a side-effect of setting its value to "" if there is 
no default?

> 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.

I did this, and it works.  Thanks.

Adrian Ashley
Broadcom Corp.





_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats