[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):

 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>