[GRASS-dev] [grass-code I][502] Grass 6.3 fails to apply database connection changes via db.connect

On 05/10/07 15:28, grass-dev@grass.itc.it wrote:

code I item #502, was opened at 2007-10-05 10:28 Status: Open Priority: 3 Submitted By: Eric Patton (eric) Assigned to: Nobody
(None) Summary: Grass 6.3 fails to apply database connection changes
via db.connect Issue type: module bug Issue status: None GRASS
version: CVS HEAD GRASS component: None Operating system: Linux Operating system version: Ubuntu 7.04 GRASS CVS checkout date, if
applies (YYMMDD): 071005

Initial Comment: I noticed that Grass 6.3 cvs doesn't 'remember' the
database changes that were applied during the last session:

Markus wrote:

Absolutely. I was also suprised yesterday and added a workaround
in lib/init/init.sh (to restore DBF if the VAR file is missing).
But I wonder what is deleting this file. This is a pretty new bug.

I actually have the feeling that your workaround actually is the problem. You added this to init.sh:

# predefine DBF driver if DB connection not defined
echo "DB_DRIVER: dbf" > "$LOCATION/VAR"
echo "DB_DATABASE: \$GISDBASE/\$LOCATION_NAME/\$MAPSET/dbf/" >> "$LOCATION/VAR"
mkdir "$LOCATION"/dbf

But I don't see any conditioning around this, so IIUC driver and database will always be set to dbf of the mapset at each startup. It probably needs a test for the dbf directory around it. Something like (not a bash expert):

if [ ! -e $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/];
   then
    echo "DB_DRIVER: dbf" > "$LOCATION/VAR"
    echo "DB_DATABASE: \$GISDBASE/\$LOCATION_NAME/\$MAPSET/dbf/" >> "$LOCATION/VAR"
    mkdir "$LOCATION"/dbf
fi

Moritz

Replying to myself after rereading what I wrote:

On 05/10/07 16:02, Moritz Lennert wrote:

But I don't see any conditioning around this, so IIUC driver and database will always be set to dbf of the mapset at each startup. It probably needs a test for the dbf directory around it. Something like (not a bash expert):

if [ ! -e $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/];
  then
   echo "DB_DRIVER: dbf" > "$LOCATION/VAR"
   echo "DB_DATABASE: \$GISDBASE/\$LOCATION_NAME/\$MAPSET/dbf/" >> "$LOCATION/VAR"
   mkdir "$LOCATION"/dbf
fi

No, this should be

if [ ! -e $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/];
    then
    mkdir "$LOCATION"/dbf
fi

And $LOCATION/VAR variables should only be preset to the dbf driver if for any reason it is empty, if at all.

Moritz

Moritz Lennert wrote:

> But I don't see any conditioning around this, so IIUC driver and
> database will always be set to dbf of the mapset at each startup. It
> probably needs a test for the dbf directory around it. Something like
> (not a bash expert):

..

if [ ! -e $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/];
    then
    mkdir "$LOCATION"/dbf
fi

And $LOCATION/VAR variables should only be preset to the dbf driver if
for any reason it is empty, if at all.

* you need a space before the closing "]" in the if statement
* you need to "quote" variable paths, they may have a space in them
* test if it's a dir, not a file (in unix everything is a file)

so the above would look like
...
LOCATION="$GISDBASE/$LOCATION_NAME/$MAPSET"
...

if [ ! -d "$LOCATION/dbf" ] ; then
    mkdir "$LOCATION"/dbf
fi

But I'm really not sure that we do need to automatically make dbf/ dirs for
each new mapset, or even create a VAR file in the mapset before it is needed.
The user may never use the DBF driver, or for that matter any database if they
just stick to raster maps.

As usual, it's better to fix the bug at the source and strictly follow good
design principals as opposed to debating work-arounds.

Hamish

      ____________________________________________________________________________________
Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos.
http://autos.yahoo.com/index.html

there is a bug in init.sh, VAR is overwritten with DBF stuff on startup, even
if you start grass with:

$ grass63 spearfish60/user1

the $MAPSET/VAR file now has a timestamp of when you (just) started GRASS..

Hamish

____________________________________________________________________________________
Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow

> code I item #502, was opened at 2007-10-05 10:28 Status: Open
> (None) Summary: Grass 6.3 fails to apply database connection changes
> via db.connect

..

> Initial Comment: I noticed that Grass 6.3 cvs doesn't 'remember' the
> database changes that were applied during the last session:

Markus wrote:
> Absolutely. I was also suprised yesterday and added a workaround
> in lib/init/init.sh (to restore DBF if the VAR file is missing).
> But I wonder what is deleting this file. This is a pretty new bug.

Moritz Lennert wrote:

I actually have the feeling that your workaround actually is the
problem. You added this to init.sh:

# predefine DBF driver if DB connection not defined
echo "DB_DRIVER: dbf" > "$LOCATION/VAR"
echo "DB_DATABASE: \$GISDBASE/\$LOCATION_NAME/\$MAPSET/dbf/" >>
"$LOCATION/VAR"
mkdir "$LOCATION"/dbf

But I don't see any conditioning around this, so IIUC driver and
database will always be set to dbf of the mapset at each startup. It
probably needs a test for the dbf directory around it. Something like
(not a bash expert):

Right. I added conditioning around that but then commented the whole bunch out.
The VAR file and $MAPSET/dbf/ dir should be created on demand, not
automatically.

Apparently Markus found a second bug for which this was a repair for, and
apparently that bug is still out in the wild and needs to be fixed. ??
Or maybe now everything is back to normal??

[leaving bug report open and commented out code in init.sh until we know]

Hamish

____________________________________________________________________________________
Pinpoint customers who are looking for what you sell.
http://searchmarketing.yahoo.com/