[GRASS-dev] Re: [GRASS-trac] #7: Location wizard: should predefine DB connection for new location

[GRASS-trac]

#7: Location wizard: should predefine DB connection for new location
----------------------+-----------------------------------------------------
  Reporter:  neteler  |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect   |      Status:  new                      
  Priority:  major    |   Milestone:  6.3.0                    
 Component:  default  |     Version:  svn-trunk                
Resolution:           |    Keywords:                           
----------------------+-----------------------------------------------------
Comment (by hamish):

 re. create VAR file for each mapset if it doesn't exist
 (see also default DB -> SQLite)


 Markus:
 > I disagree and think that new locations should be valid locations -
 ..

 Michael:
 > But we should not be creating locations that have hidden gotchas.

 In that case, wouldn't all locations / datasets created with earlier
 versions of grass be considered invalid?
 (if so we need to re-add auto-creation of VAR in init.sh)


 Markus:
 > or - *all* modules should be able to work with locations lacking
 > the VAR file.

 This is the solution I would like to pursue. Can anyone give examples of
 which modules break? AFAIK they have all been fixed (v.db.add*).
 Do any remain?



 > No complaints in 6.2 probably because use cases are different.

 How so? I don't understand what changed. Changes to/new v.db.add*??


 For fixing C modules it should be as hard as testing a return value and
 calling G_fatal_error() with "DB unset. Please run db.select".
 For scripts it should be as simple as either calling db.select in the
 script if unset or just letting the C module's G_fatal_error() spit out
 the appropriate error.



 > I see no point in having this trivial thing lacking and then make
 > the user stumble about several commands not functioning.
 ..
 > If we have a default DBMI driver (which is yet DBF), we also have
 > to set default settings.
 ..
 > Scripts like v.db.add* cannot run that automatically because we
 > don't want to hardcode DBF (or whatever driver) many times
 > scattered all over the source code but only in a single place

 I agree it should be set in a single place and it is annoying to go
 through the step manually.

 v.in.ascii (.c) creates dbf/ and sets it as default if it doesn't exist:
 [new mapset]
 G6.3svn> echo "1 2 foo bar" | v.in.ascii out=foomap fs=space x=1 y=2
 Scanning input for column types...
 Maximum input row length: 12
 Maximum number of columns: 4
 Minimum number of columns: 4
 WARNING: Default driver / database set to:
          driver: dbf
          database: $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/
 Importing points...
 ...


 this happens in.c (aka v.in.ascii's main.c),
  Fi = Vect_default_field_info(&Map, 1, NULL, GV_1TABLE);

 which is from lib/vector/Vlib/field.c  Vect_default_field_info()
  (hardcoded to DBF)

 so any C module which creates a new table should use/check that?
 AFAICT that seems to be the case for the C modules.
 grass63/vector$ grep -rI Vect_default_field_info * | \
   grep -v \.svn | cut -f1 -d/


 If db.select + default values is not sufficient for a single place there
 could be a maintenance script which tests and sets the default DB when
 needed. ? v.db.add* scripts could call that. I am happy to author that if
 it is decided to go that way.



 > (which was the init script and I still complain that this was
 > removed leading to broken DBMI settings - see the archive for
 > this).

 - I hadn't understood the reason for putting it in init.sh was that was
 supposed to be the central default DB set point. If that is to be the case
 it's better to put that in a support script than in init.sh

 - Initially removed due to nasty scripting bug which overwrote VAR
 unconditionally, so if anyone decides to revert the removal, please
 take care not to reintroduce that.


 > The "file system noise" is in average 70 bytes (!) per MAPSET
 > which can be just ignored as a problem.

 I don't know if the joke translates well from English, but there is an old
 saying "cleanliness is next to impossible." But still a worthy goal.


 Vect_default_field_info() limits it to scripts which don't create tables
 without using other C modules, and we can code a support script module to
 handle those cases with only 1 line a module.


 Hamish

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/7#comment:7>
GRASS-trac <http://grass.osgeo.org>
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/