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

[GRASS GIS]

#809: v.db.addtable consistently fails in winGrass
------------------------------+---------------------------------------------
  Reporter:  JonBall          |       Owner:  grass-dev at 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>