[GRASS-dev] [GRASS GIS] #809: v.db.addtable consistently fails in winGrass

GDAL · November 13, 2009, 3:30pm

#809: v.db.addtable consistently fails in winGrass
----------------------+-----------------------------------------------------
Reporter: JonBall | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: blocker | Milestone: 6.4.0
Component: Vector | Version: svn-trunk
Keywords: addtable | Platform: MSWindows Vista
Cpu: x86-64 |
----------------------+-----------------------------------------------------
Platform: Vista
grass obtained from: Trento Italy site
grass binary for platform: as Downloaded
GRASS Version: 6.4.0SVN (r39626) 2009-10-27

v.db.addtable consistently fails but returns no error message. When I try
to use this command at the Windows Grass Command Line (Windows shell), I
always get an empty shell prompt:

---------
GRASS 6.4.0svn (spearfish60)> v.db.addtable map=mysoils layer=2 col="left
intege
r,right integer"
"C:/GRASS-6-SVN/msys/bin/sh.exe"-2.04$
---------

The only apparent way to proceed it to type 'exit' at the shell prompt and
the command will terminate without creating a table. I am trying to
reproduce the script in the documentation for v.to.db
(http://grass.itc.it/grass64/manuals/html64_user/v.to.db.html - "Upload
category numbers of left and right area, to an attribute table of
boundaries common for the areas").

This error is consistent whatever data I try and use, whether it is the
demo Spearfish60, North-Carolina or some other data.

I have reproduced the same error on two independent installations of
winGrass on two different machines (both using the same pre-compiled
binaries).

I have tried switching to sqlite (same error). I have tried re-installing
winGrass.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/809>
GRASS GIS <http://grass.osgeo.org>

GDAL · November 13, 2009, 3:41pm

#809: v.db.addtable consistently fails in winGrass
------------------------------+---------------------------------------------
  Reporter: JonBall | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Vector | Version: svn-releasebranch64
Resolution: | Keywords: addtable
  Platform: MSWindows Vista | Cpu: x86-64
------------------------------+---------------------------------------------
Changes (by martinl):

* priority: blocker => critical
* version: svn-trunk => svn-releasebranch64

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/809#comment:1>
GRASS GIS <http://grass.osgeo.org>

GDAL · November 13, 2009, 5:21pm

#809: v.db.addtable consistently fails in winGrass
------------------------------+---------------------------------------------
  Reporter: JonBall | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Vector | Version: svn-releasebranch64
Resolution: | Keywords: addtable
  Platform: MSWindows Vista | Cpu: x86-64
------------------------------+---------------------------------------------
Comment (by hellik):

tested in MSYS-shell:

{{{
GRASS 6.4.0svn (nc_spm_08):c:/osgeo4w/apps/grass/bin > v.db.addtable
map=mysoils layer=2 col="left integer, right int
eger"
Using vector map name extended by layer number as table name: mysoils_2
Creating table with columns (cat integer, left integer, right integer)
The table <mysoils_2> is now part of vector map <mysoils> and may be
deleted or overwritten by GRASS modules
Select privileges were granted on the table
Reading features...
100%
Updating database...
100%
0 categories read from vector map (layer 2)
0 records updated/inserted (layer 2)
Current attribute table links:
layer <1> table <mysoils> in database
<C:\gisdata\grassdata/nc_spm_08/user1/dbf/> through driver <dbf> with key
<cat>
layer <2> table <mysoils_2> in database
<C:\gisdata\grassdata/nc_spm_08/user1/dbf/> through driver <dbf> with key
<cat>
Vector map <mysoils@user1> is connected by:
GRASS 6.4.0svn (nc_spm_08):c:/osgeo4w/apps/grass/bin >
}}}

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/809#comment:2>
GRASS GIS <http://grass.osgeo.org>

GDAL · December 6, 2009, 8:07am

#809: v.db.addtable consistently fails in winGrass
------------------------------+---------------------------------------------
  Reporter: JonBall | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Vector | Version: svn-releasebranch64
Resolution: | Keywords: v.db.addtable, wingrass
  Platform: MSWindows Vista | Cpu: x86-64
------------------------------+---------------------------------------------
Changes (by hamish):

* keywords: addtable => v.db.addtable, wingrass

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/809#comment:3>
GRASS GIS <http://grass.osgeo.org>

GDAL · January 6, 2010, 12:27am

#809: v.db.addtable consistently fails in winGrass
------------------------------+---------------------------------------------
  Reporter: JonBall | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Vector | Version: svn-releasebranch64
Resolution: | Keywords: v.db.addtable, wingrass
  Platform: MSWindows Vista | Cpu: x86-64
------------------------------+---------------------------------------------
Comment (by hamish):

hopefully fixed by r40271. please test, as like hellik I can't reproduce
it.

I notice that v.db.droptable is not available from the GUI menu?

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/809#comment:4>
GRASS GIS <http://grass.osgeo.org>

GDAL · January 6, 2010, 1:10am

#809: v.db.addtable consistently fails in winGrass
------------------------------+---------------------------------------------
  Reporter: JonBall | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Vector | Version: svn-releasebranch64
Resolution: | Keywords: v.db.addtable, wingrass
  Platform: MSWindows Vista | Cpu: x86-64
------------------------------+---------------------------------------------
Comment (by hamish):

hmm, there is still a quoting bug in v.to.db called by v.db.addtable:

{{{
Reading features...
100%
and: no such driver available
WARNING: unable to start driver <and>
ERROR: Unable to open database <C:\Documents> by driver <and>
}}}

(the mapset is in C:\Documents and Settings\)

ah, here we go: Line 634 of lib/vector/Vlib/field.c scanning the dbln file
does not like spaces in the db path string-

{{{
ndef = sscanf(buf, "%s %s %s %s %s", fldstr, tab, col, db, drv);
}}}

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/809#comment:5>
GRASS GIS <http://grass.osgeo.org>

GDAL · January 6, 2010, 1:15am

#809: v.db.addtable consistently fails in winGrass
------------------------------+---------------------------------------------
  Reporter: JonBall | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Vector | Version: svn-releasebranch64
Resolution: | Keywords: v.db.addtable, wingrass
  Platform: MSWindows Vista | Cpu: x86-64
------------------------------+---------------------------------------------
Comment (by hamish):

Replying to [comment:5 hamish]:
> ah, here we go: Line 634 of lib/vector/Vlib/field.c scanning the
> dbln file does not like spaces in the db path string-
>
> {{{
> ndef = sscanf(buf, "%s %s %s %s %s", fldstr, tab, col, db, drv);
> }}}

(I've got no idea how to fix that)

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/809#comment:6>
GRASS GIS <http://grass.osgeo.org>

GDAL · January 6, 2010, 1:24am

#809: v.db.addtable consistently fails in winGrass
------------------------------+---------------------------------------------
  Reporter: JonBall | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Vector | Version: svn-releasebranch64
Resolution: | Keywords: v.db.addtable, wingrass
  Platform: MSWindows Vista | Cpu: x86-64
------------------------------+---------------------------------------------
Comment (by hamish):

note you have to be using layer 2 or greater to see this. for layer 1 the
DB path is still the unparsed "$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/". On
the next iteration for layer 2 it is converted to the real expanded path.

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/809#comment:7>
GRASS GIS <http://grass.osgeo.org>

GDAL · January 6, 2010, 8:28am

#809: v.db.addtable consistently fails in winGrass
------------------------------+---------------------------------------------
  Reporter: JonBall | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Vector | Version: svn-releasebranch64
Resolution: | Keywords: v.db.addtable, wingrass
  Platform: MSWindows Vista | Cpu: x86-64
------------------------------+---------------------------------------------
Comment (by mmetz):

Replying to [comment:7 hamish]:
> note you have to be using layer 2 or greater to see this. for layer 1
the DB path is still the unparsed "$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/".
On the next iteration for layer 2 it is converted to the real expanded
path.

I think this is a bug. v.db.addtable should always use the default,
unparsed database connection settings because there is no database option
in v.db.addtable.

If a table already exists in layer 1 and a new table is to be added for
another layer, v.db.addtable uses the definition for layer 1 as returned
by v.db.connect -g which parses "$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/".
Suggested fix would be to always use the default unparsed database
connection, i.e. skip the check in v.db.addtable lines 119 - 136
(grass64).

Markus M

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/809#comment:8>
GRASS GIS <http://grass.osgeo.org>

GDAL · January 6, 2010, 12:33pm

#809: v.db.addtable consistently fails in winGrass
------------------------------+---------------------------------------------
  Reporter: JonBall | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Vector | Version: svn-releasebranch64
Resolution: | Keywords: v.db.addtable, wingrass
  Platform: MSWindows Vista | Cpu: x86-64
------------------------------+---------------------------------------------
Comment (by hamish):

Hamish:
> hmm, there is still a quoting bug in v.to.db called by
> v.db.addtable:
...
> ah, here we go: Line 634 of lib/vector/Vlib/field.c scanning
> the dbln file does not like spaces in the db path string-
>
{{{
ndef = sscanf(buf, "%s %s %s %s %s", fldstr, tab, col, db, drv);
}}}
> note you have to be using layer 2 or greater to see this.

I'm guessing G_tokenize(buf, ' ') + the same approach taken by the wxGUI
for this some weeks ago and pull off db as tokens 4 to (ntok-1) and then
drv with the last of G_number_of_tokens()?

I suppose a similar thing could be done with strrchr() to chop the drv off
the string first, set strrchr() to '\0', then to get db go back and read
{{{ %[^\n] }}} to the end of the remaining line?

any recommendations from C string parsing experts?

Replying to [comment:8 mmetz]:
> I think this is a bug. v.db.addtable should always use the
> default, unparsed database connection settings because there
> is no database option in v.db.addtable.

note that layer 2 parsing is done by libvect (called by v.to.db) doing the
damage here as it scans through the layers, if the shell script does
expansion or not, it is more general & will fail with any dbln with a
space in the path. the script expansion just makes this bug be triggered
more often.

{{{
# finally we have to add cats into the attribute DB to make modules such
as v.what.rast happy:
# (creates new row for each vector line):
}}}

what you mention here is a secondary "feature" (which probably doesn't
help) who's main draw back is that it makes the vector map less portable.

> If a table already exists in layer 1 and a new table is to
> be added for another layer, v.db.addtable uses the definition
> for layer 1 as returned by v.db.connect -g which parses
> "$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/". Suggested fix would be
> to always use the default unparsed database connection,
> i.e. skip the check in v.db.addtable lines 119 - 136 (grass64).

hmmm ok;

{{{
g.copy v=roads,myroads
v.db.addtable myroads layer=2 col="left integer, right integer"

dbln:
1 myroads cat $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ dbf
2 myroads_2 cat /home/hamish/grassdata/spearfish60/user1/dbf/ dbf
}}}

if a layer 1 exists* it uses the default mapset/VAR values from
db.connect, see lines 124-125 and 131-132. it only reuses (&expands) layer
1's DB path definition on line 128. A secondary question is should the new
layer prefer to use the mapset's default DB or the map's existing layer 1
DB? I don't know the answer to that, I think we just have to pick one.

Is there a command print the unexpanded version or do we just resort to
raw parsing of the dbln file to get it?

[*] (is it possible for there to be no layer 1 but do have a layer >1? if
so will that cause problems for this script?)

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/809#comment:9>
GRASS GIS <http://grass.osgeo.org>

GDAL · January 6, 2010, 12:38pm

#809: v.db.addtable consistently fails in winGrass
------------------------------+---------------------------------------------
  Reporter: JonBall | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Vector | Version: svn-releasebranch64
Resolution: | Keywords: v.db.addtable, wingrass
  Platform: MSWindows Vista | Cpu: x86-64
------------------------------+---------------------------------------------
Comment (by hamish):

Replying to [comment:9 hamish]:
> I'm guessing G_tokenize(buf, ' ') + the same approach taken
> by the wxGUI for this some weeks ago and pull off db as tokens
> 4 to (ntok-1) and then drv with the last of G_number_of_tokens()?
>
> I suppose a similar thing could be done with strrchr() to chop
> the drv off the string first, set strrchr() to '\0', then to
> get db go back and read {{{ %[^\n] }}} to the end of the
> remaining line?

an advantage of the G_tokenize() approach is that we can check for a
minimum number of tokens.

> if a layer 1 exists* it uses the default mapset/VAR values from
> db.connect,

that should read "does not exist"

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/809#comment:10>
GRASS GIS <http://grass.osgeo.org>

GDAL · January 7, 2010, 12:14pm

#809: v.db.addtable consistently fails in winGrass
------------------------------+---------------------------------------------
  Reporter: JonBall | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Vector | Version: svn-releasebranch64
Resolution: | Keywords: v.db.addtable, wingrass
  Platform: MSWindows Vista | Cpu: x86-64
------------------------------+---------------------------------------------
Comment (by hamish):

stuff to audit, both for spaces in path names and for correct column
parsing when fs=':' and a path like "C:\Documents and Settings" is being
parsed.

{{{
lib/db/
dbmi_base/login.c: ret = sscanf(buf, "%[^ ] %[^ ] %[^ ] %[^ ]", dr,
db, usr, pwd);
dbmi_base/dbmscap.c: if (sscanf(buf, "%[^:]:%[^:]:%[^:\n]", name,
startup, comment) == 3)
dbmi_base/dbmscap.c: else if (sscanf(buf, "%[^:]:%[^:\n]", name,
startup) == 2)

lib/vector/
Vlib/field.c: ndef = sscanf(buf, "%s %s %s %s %s", fldstr, tab, col, db,
drv);
}}}

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/809#comment:11>
GRASS GIS <http://grass.osgeo.org>

GDAL · January 8, 2010, 8:42am

#809: v.db.addtable consistently fails in winGrass
------------------------------+---------------------------------------------
  Reporter: JonBall | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Vector | Version: svn-releasebranch64
Resolution: | Keywords: v.db.addtable, wingrass
  Platform: MSWindows Vista | Cpu: x86-64
------------------------------+---------------------------------------------
Comment (by mmetz):

Replying to [comment:11 hamish]:
> stuff to audit, both for spaces in path names and for correct column
parsing when fs=':' and a path like "C:\Documents and Settings" is being
parsed.

I had a look at the vector lib routines for reading/writing database
connections (dblinks in the vector libs).

The database is written to dbln without parsing any variables in it; that
makes it possible to copy entire locations or provide sample datasets with
vectors and attribute tables. Any variables in the database info are
parsed by Vect_get_dblink() which calls Vect_subst_var().

v.db.addtable calls v.db.connect which calls Vect_get_dblink() -> any
variables like $GISDBASE/$LOCATION_NAME/$MAPSET are already substituted.

The only way I see to get the database used by an existing layer *without*
parsing any variables is raw parsing of the dbln file. AFAICT, vector
modules use default database connection settings when adding a new table,
also when e.g. adding a table for layer 2 and there is already a table
connected to layer 1. Therefore it would not be unusual behaviour if
v.db.addtable also always uses the default database connections.

Markus M

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/809#comment:12>
GRASS GIS <http://grass.osgeo.org>

GDAL · January 8, 2010, 9:51am

#809: v.db.addtable consistently fails in winGrass
------------------------------+---------------------------------------------
  Reporter: JonBall | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Vector | Version: svn-releasebranch64
Resolution: | Keywords: v.db.addtable, wingrass
  Platform: MSWindows Vista | Cpu: x86-64
------------------------------+---------------------------------------------
Comment (by hamish):

> Replying to [comment:11 hamish]:
> > stuff to audit, both for spaces in path names and for correct
> > column parsing when fs=':' and a path like "C:\Documents and
> > Settings" is being parsed.

Replying to [comment:12 mmetz]:
> I had a look at the vector lib routines for reading/writing
> database connections (dblinks in the vector libs).
>
> The database is written to dbln without parsing any variables in
> it; that makes it possible to copy entire locations or provide
> sample datasets with vectors and attribute tables. Any variables
> in the database info are parsed by Vect_get_dblink() which calls
> Vect_subst_var().

However, there is no reason to assume that the user has not manually
connected the vector to a real pathname. And in those cases any code which
reads the dbln file will need to be able to deal with databases with
spaces in the path name.

suggestion: This is really a failure of the dbln file format. In grass 7
change the dbln file format to use '|' as the field sep. Include code in
both the g7 and g6.5 the library functions to quietly read either during
the transition period. We have done something similar for the color table
format which used to be "value red green blue" but is now "value
red:green:blue".

> v.db.addtable calls v.db.connect which calls Vect_get_dblink() ->
> any variables like $GISDBASE/$LOCATION_NAME/$MAPSET are already
> substituted.
>
> The only way I see to get the database used by an existing layer
> *without* parsing any variables is raw parsing of the dbln file.

I came to the same conclusion and checked in that exact fix to svn a
couple of hours ago.

> AFAICT, vector modules use default database connection settings
> when adding a new table, also when e.g. adding a table for layer
> 2 and there is already a table connected to layer 1. Therefore it
> would not be unusual behaviour if v.db.addtable also always uses
> the default database connections.

For now I have followed the path of least change and left it using what
the map is already using. One thing I see in favor of having it use the
mapset's VAR setting instead is that you can control the VAR setting. You
can't control what the map already has in it unless you rebuild the map
(which is perhaps not what you want). Another plausible possibility is to
add database= and driver= options to v.db.addtable.

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/809#comment:13>
GRASS GIS <http://grass.osgeo.org>

GDAL · January 8, 2010, 9:59am

#809: v.db.addtable consistently fails in winGrass
------------------------------+---------------------------------------------
  Reporter: JonBall | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Vector | Version: svn-releasebranch64
Resolution: | Keywords: v.db.addtable, wingrass
  Platform: MSWindows Vista | Cpu: x86-64
------------------------------+---------------------------------------------
Comment (by hamish):

Replying to [comment:13 hamish]:
> Another plausible possibility is to add database= and
> driver= options to v.db.addtable.

fwiw if it is to change I prefer the VAR option as it keeps v.db.addtable
simple.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/809#comment:14>
GRASS GIS <http://grass.osgeo.org>

GDAL · January 8, 2010, 10:21am

#809: v.db.addtable consistently fails in winGrass
------------------------------+---------------------------------------------
  Reporter: JonBall | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Vector | Version: svn-releasebranch64
Resolution: | Keywords: v.db.addtable, wingrass
  Platform: MSWindows Vista | Cpu: x86-64
------------------------------+---------------------------------------------
Comment (by mmetz):

Replying to [comment:13 hamish]:
> Replying to [comment:12 mmetz]:
> > I had a look at the vector lib routines for reading/writing
> > database connections (dblinks in the vector libs).
> >
> > The database is written to dbln without parsing any variables in
> > it; that makes it possible to copy entire locations or provide
> > sample datasets with vectors and attribute tables. Any variables
> > in the database info are parsed by Vect_get_dblink() which calls
> > Vect_subst_var().
>
> However, there is no reason to assume that the user has not manually
connected the vector to a real pathname. And in those cases any code which
reads the dbln file will need to be able to deal with databases with
spaces in the path name.

Right, and it should also be broken on Linux if there are whitespaces in
the path name when manually connecting a table. A mystery that no one
discovered that yet...
>
> suggestion: This is really a failure of the dbln file format. In grass 7
change the dbln file format to use '|' as the field sep. Include code in
both the g7 and g6.5 the library functions to quietly read either during
the transition period. We have done something similar for the color table
format which used to be "value red green blue" but is now "value
red:green:blue".

OK. And use G_tokenize() I assume.
>
> You can't control what the map already has in it unless you rebuild the
map (which is perhaps not what you want). Another plausible possibility is
to add database= and driver= options to v.db.addtable.

Makes sense, and should not make the code too complicated. Something for
g7?

Markus M

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/809#comment:15>
GRASS GIS <http://grass.osgeo.org>

GDAL · January 8, 2010, 11:11am

#809: v.db.addtable consistently fails in winGrass
------------------------------+---------------------------------------------
  Reporter: JonBall | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Vector | Version: svn-releasebranch64
Resolution: | Keywords: v.db.addtable, wingrass
  Platform: MSWindows Vista | Cpu: x86-64
------------------------------+---------------------------------------------
Comment (by hamish):

I've just attached to this ticket a patch against 6.5 which allows spaces
in pathnames for hardcoded database paths using G_tokenize().

please review.

previously there was behavior in Vect_read_dblinks() which allowed the
dbln file to only contain the layer number and table name if you'd already
defined the others in previous layer links.

I've tried to preserve that, but if the path has spaces I don't think it
is possible to distinguish between if the last entry is supposed to be the
driver or the end of the path name. Therefore we lose a tiny bit of
functionality here, but I don't think anyone knew about or was using that
trick anyway.

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/809#comment:16>
GRASS GIS <http://grass.osgeo.org>

GDAL · January 8, 2010, 11:24am

#809: v.db.addtable consistently fails in winGrass
------------------------------+---------------------------------------------
  Reporter: JonBall | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Vector | Version: svn-releasebranch64
Resolution: | Keywords: v.db.addtable, wingrass
  Platform: MSWindows Vista | Cpu: x86-64
------------------------------+---------------------------------------------
Comment (by hamish):

Replying to [comment:15 mmetz]:
> Right, and it should also be broken on Linux if there are
> whitespaces in the path name when manually connecting a table.

I just tested, it is.

> A mystery that no one discovered that yet...

I suspect they probably have, we've just never put all the pieces together
before. Especially Mac users who are more likely to see spaces in path
names.

> > suggestion: This is really a failure of the dbln file format.
> > In grass 7 change the dbln file format to use '|' as the field
> > sep. Include code in both the g7 and g6.5 the library functions
> > to quietly read either during the transition period.
...
> OK. And use G_tokenize() I assume.

in G_parser() is a G_tokenize() call which defines the sep as a two-
character array, which would be an easy way to temporarily allow either |
or " " as the sep.

> > You can't control what the map already has in it unless you
> > rebuild the map (which is perhaps not what you want). Another
> > plausible possibility is to add database= and driver= options
> > to v.db.addtable.
>
> Makes sense, and should not make the code too complicated.
> Something for g7?

or now or 6.4.1, if it is decided that inability to set a different DB for
new tables with v.db.addtable is actually a bug. (I guess you can already
adjust it to the desired value v.db.connect after creation, but that's a
bit ugly)

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/809#comment:17>
GRASS GIS <http://grass.osgeo.org>

GDAL · January 8, 2010, 6:11pm

#809: v.db.addtable consistently fails in winGrass
------------------------------+---------------------------------------------
  Reporter: JonBall | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Vector | Version: svn-releasebranch64
Resolution: | Keywords: v.db.addtable, wingrass
  Platform: MSWindows Vista | Cpu: x86-64
------------------------------+---------------------------------------------
Comment (by mmetz):

Replying to [comment:16 hamish]:
> I've just attached to this ticket a patch against 6.5 which allows
spaces in pathnames for hardcoded database paths using G_tokenize().
>
> please review.

Tested, works fine. One minor bug though: in the new v.db.addtable line
129
{{{
eval `g.findfile elem="vector/$GIS_OPT_MAP" file=dbln`
}}}
does not work with a fully qualified name, the default settings in
$MAPSET/VAR are used. Maybe something like
{{{
eval `g.findfile elem=vector file=$GIS_OPT_MAP`
eval `g.findfile elem=vector/$name file=dbln mapset=$mapset`
}}}
?
>
> previously there was behavior in Vect_read_dblinks() which allowed the
dbln file to only contain the layer number and table name if you'd already
defined the others in previous layer links.
>
> I've tried to preserve that, but if the path has spaces I don't think it
is possible to distinguish between if the last entry is supposed to be the
driver or the end of the path name. Therefore we lose a tiny bit of
functionality here, but I don't think anyone knew about or was using that
trick anyway.

In grass64+, Vect_write_dblinks() always writes the full connection
definition, so I would not worry too much. I have not looked at previous
versions though to see if for layers > 1, only layer number and table name
were written if the rest was identical to layer 1.

For grass7, I would suggest to use fs="|" as default (anything but
whitespace) whenever dblinks are written or printed, e.g.
Vect_write_dblinks() and v.db.connect -p

Markus M

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/809#comment:18>
GRASS GIS <http://grass.osgeo.org>

GDAL · January 9, 2010, 5:14am

#809: v.db.addtable consistently fails in winGrass
------------------------------+---------------------------------------------
  Reporter: JonBall | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Vector | Version: svn-releasebranch64
Resolution: | Keywords: v.db.addtable, wingrass
  Platform: MSWindows Vista | Cpu: x86-64
------------------------------+---------------------------------------------
Comment (by hamish):

Replying to [comment:18 mmetz]:
> Replying to [comment:16 hamish]:
> > I've just attached to this ticket a patch against 6.5 which
> > allows spaces in pathnames
...
> Tested, works fine.

committed in 6.5svn and trunk.

> One minor bug though: in the new v.db.addtable line 129
[g.findfile]
> does not work with a fully qualified name,

interestingly it pretty much works if you just chop off the @mapset
part because g.findfile searches the full mapset path as a module would.

Anyway, I've ripped this code out now in favor of using the VAR file's
default DB settings for the mapset. So you are able to now control it
instead of being locked to what the map was already using. Committed in
6.5svn and trunk.

> For grass7, I would suggest to use fs="|" as default
> (anything but whitespace) whenever dblinks are written or
> printed, e.g. Vect_write_dblinks() and v.db.connect -p

Done and done. I'm sure we'll hear about it if there are any problems, but
after some light testing it seems to work ok.

the only thing left to decide is when to backport this stuff to 6.4.

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/809#comment:19>
GRASS GIS <http://grass.osgeo.org>