Re: use of GNATSDB

[Mel Hatzis]

Looking at the use of the GNATSDB environment variable
throughout the code, it seems somewhat ambiguous.

On the one hand, it can be set to a database name
corresponding to an entry in the databases file, and on
the other hand, it can be set to a colon separated tuple
defining a 'remote' database, as follows:
   hostname:portnumber:databasename:username:password

I'd like to suggest that two variables be used for these
different purposes to cleanly delineate and clearly specify
the intended functionality.

My proposal is to continue to use GNATSDB as the
'colon separated tuple' and introduce GNATSID to
replace the use of GNATSDB in findOrLoadDatabase
(in database.c).

I've included an earlier email exchange related to the topic
below...

My apologies if this is not the right forum for such a
discussion.

--
Mel Hatzis
Juniper Networks, Inc.

Hans-Albert Schneider wrote:
> > > > > > "Mel" == Mel Hatzis <address@hidden> writes:
>
>     Mel> I believe I have the latest code...version 1.42 of
>     Mel> client.c.
>
> Yes, that's the version I've got, too.
>
>     Mel> The problem occurs around 13 lines from the bottom of
>     Mel> the scanEnv function...
>
>     Mel>     if (*database == NULL)
>     Mel>       {
>     Mel>         *database = xstrdup ("default");
>     Mel>       }
>
>     Mel> If you look closely, you'll note that even though the
>     Mel> env. variable is read, it is not used to initialize the
>     Mel> 'database' variable....and therefore, the lines I've
>     Mel> pasted above end up setting it to 'default'.
>
> I see... It is even a bit more complicated:
>
> If GNATSDB is a colon separated tuple of
>         hostname:portnumber:databasename:username:password
> then "database" gets initialized, but not if it is the name of a
> database listed in the "databases" file.
>
> (The tuple format is described in the manual in "Environment
> variables and GNATS tools" in chapter "The GNATS user tools".  It
> is probably intended for databases that must be accessed across
> the net, but are not listed in the "databases" file.)
>
> Even worse: I do not see how scanEnv deals with a *local*
> database at all.
>
> A workaround seems to be to specify the database name via option
> --database or -d.  This is passed to client_init_gnats(), then to
> scanEnv(), and is left untouched.
>
>
> I don't dare to change the code, because I do not know it good
> enough to be sure not to break another place.
>
>
> Hans-Albert