#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
