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

[Michael Barton]

> #7: Location wizard: should predefine DB connection for new location
> ---------------------- 
> +-----------------------------------------------------
>   Reporter:  neteler  |       Owner:  hamish
>       Type:  defect   |      Status:  assigned
>   Priority:  major    |   Milestone:  6.4.0
>  Component:  default  |     Version:  svn-trunk
> Resolution:           |    Keywords:
> ---------------------- 
> +-----------------------------------------------------
> Comment (by hamish):
>
>  Eric wrote:
>> I created a new location using today's svn source, and noticed that
>> db.connect doesn't have its database parameter pre-populated with
>> $GISDBASE/$LOCATION_NAME/$MAPSET/dbf as it used to; it is now blank.
>> Possible bug? Would it possible to get the module to at least  
>> populate
>> $GISDBASE/$LOCATION_NAME/$MAPSET for this parameter?
>
>  db.connect takes its default driver, database, schema, and group  
> settings
>  from the $MAPSET/VAR file by way of the db_get_default_*_name() fns.
>  (lib/db/dbmi_base/default_name.c)  This is a circular chicken-or-egg
>  situation. (the default is to set it back to what it already is,  
> which is
>  a redundant task)
>
>
>  Martin:
>> yes, see
>> http://trac.osgeo.org/grass/ticket/7
>>
>> It seems to me that the VAR file should defined for newly created
>> mapset by default to avoid possible problems.
>
>  that approach deals with the symptoms, but doesn't address the  
> underlying
>  problem: what to do when the default DB settings are unknown. To be
>  robust it needs to be dealt with at module run-time and it needs  
> to fail
>  in a safe way if the VAR file is somehow damaged.
>
>
>  A secondary issue is abstracting the default DB settings back to  
> one place
>  so that when we make the switch to sqlite-as-default, we don't  
> have to
>  change ad hoc VAR file & dbf/ directory creation code in a dozen  
> places.
>
>  - For C code this was already condensed into  
> Vect_default_field_info() but
>  could be abstracted further*,
>
>  - For shell scripts we can add a new flag to db.connect* to check  
> if the
>  DB is set, and if not then set it. This would then be called from all
>  scripts which create vector tables outside of v.* modules, and  
> could be
>  used in init.sh too. (although if we have done everything  
> correctly then
>  we won't need to put it in init.sh or any other mapset creation code;
>  thus I suggest we keep it out of init.sh)
>
>  [*] now in SVN/trunk as DB_DEFAULT_DRIVER,  
> db_set_default_connection(),
>  and 'db.connect -c'. (r30545) Init.sh and various scripts are now  
> updated
>  to use that.
>
>
>  Eric:
>> Thanks for the pointer. I'll hardcode my database paths for now.
>
>  see the db.connect help page example for DBF (I usually just cut and
>  paste that to the command line when needed). It accepts variable
>  LOCATION, MAPSET, you don't need to hardcode it. (Be sure to keep the
>  path with $VARIABLES in single quotes!)
>
>
>  Martin:
>> anyway if you run some command which calls Vect_default_field_info()
>> from Vlib, VAR file is created and default driver set up to dbf.
>>
>> e.g. g.copy vect=
>
>  i.e. any C vector module which goes down that street should do the  
> trick.
>  The vector lib will set the default database if it goes to find it  
> and
>  finds it unset.
>
>
>  Paul:
>> Also I posted a suggested solution to the dev list a while ago, but
>> there were no comments.
>
>  could you post a link to that in the bug report?
>
>
>>> It seems to me that the VAR file should defined for newly created
>>> mapset by default to avoid possible problems.
>>
>> For every mapset, or just for each location? If for every mapset,  
>> should
>> it be inherited from whatever the setting for PERMANENT is, or just
>> blindly set to dbf every time a new mapset is created? If it does  
>> have
>> to be created for every mapset and inherited from PERMANENT,  
>> presumably
>> the state of the DB connection for PERMANENT can't be determined
>> without using Vectlib functions? But all the mapset/location-handling
>> functions are in GISlib, and it would really not be a good idea to  
>> have
>> GIS dependent on Vectlib functions (I think). So this is really quite
>> complicated. Perhaps the functions that deal with the default  
>> database
>> settings could be moved out of Vectlib and into GISlib.
>
>  whoa, keep it simple. if it is requested and not set, then set it. as
>  long as C vector modules are funneled through a single vector lib
>  function which checks & sets, and scripts doing low level stuff don't
>  make assumptions, we should be ok.
>
>  Michael:
>> I'm with Marcus and Martin on this. The potential for problems is  
>> high
>> if this is not done; the cost to do it is very small. Can we just go
>> ahead and make this change to g.proj?
>
>  But it's not high. I commented out the auto VAR file creation  
> sometime
>  before Christmas, and this is the first actual-usage complaint  
> I've heard.
>  And it's not even a complaint, Eric just noticed that it wasn't  
> set and
>  was wondering why.
>
>  [now I've made it live again in init.sh, but I still don't really  
> think it
>  should be there; at least the 'mkdir dbf/' stuff is out of init.sh  
> now]
>
>  AFAIK we are not (primarily) talking about g.proj, we are talking  
> about
>  Init.sh. If mapset/location creation is a problem all we have to  
> is keep
>  the 'db.connect -c' in init.sh and it will get the VAR file the  
> first time
>  the mapset is accessed.
>
>
>  Paul:
>> Attached is a patch (completely untested) that illustrates my idea  
>> for
>> solving the problem.
>
>  now obviated?
>
>> I think there should also be something in lib/gis/make_mapset.c  
>> (used by
>> g.mapsets) but there are some complications there in relation to
>> inheriting the DB settings; see my earlier mail.
>
>  (*g.mapset* not *g.mapsets*)
>
>  .... I still don't think this belongs in any mapset creation code and
>  don't think a VAR file should be included in the minimum  
> requirements for
>  the definition of a valid mapset (ie 'dir/WIND').
>
>
>
>  Hamish

If we want this to be easily changeable in the future, it should be  
dealt with in a central place (g.proj, init.sh [or its replacement],  
etc) so that changing it once will switch from a dbf to sqlite default.

This has come up periodically over the past year, as lack of a VAR  
file seems to cause different scattered modules to fail, and is  
usually puzzling to users as to what is going wrong.

It sounds like this can be fixed 2 ways: change g.proj to create a  
VAR file when it creates a location (this is how locations are  
created in the location wizard) or change modules to gracefully deal  
with the lack of a VAR file. The ongoing discussion about which of  
these two ways to fix it has left this unfixed for months. I'm  
agnostic about which way is best, except that I don't think that we  
should hack it into the location wizard wxPython code.

Michael