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