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

 Comment (by hamish):
 >  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)

 No, because it was there unless you took it out...

 >  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?

 AFAIK all db.* modules and scripts at least. Also I suspect the v.*
 scripts
 to face a problem.


 ...
 >  v.in.ascii (.c) creates dbf/ and sets it as default if it doesn't
 exist:

 g.proj does not for example.
 Likewise possibly v.in.ogr and r.in.gdal (and other modules which
 generate locations)


 >  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/

 Please also check all pure db.* modules.


 ...
 >  > 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.

 I think we have quite some more severe other problems... think about all
 the todo's concerning buffer sizes.

 >
 >  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.

 Still someone has to check all modules/scripts...
 And as mentioned: the db.* modules do not call Vect_*().

 Markus

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