#2258: t.create creates DB always in the PERMANENT
-------------------------+--------------------------------------------------
Reporter: martinl | Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Temporal | Version: svn-releasebranch70
Keywords: t.register | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by huhabla):
Replying to [comment:10 hamish]:
> This is a serious design flaw.
>
> GRASS modules should NEVER expect to be able to write outside their own
mapset directory tree.
Yes, you are right, it is a serious design flaw that breaks GRASS
completely. And there are absolutely no modules in GRASS that write
outside their own mapset directory tree. Modules able to produce file
output anywhere in the file system and modules that use SQL database
backends other than dbf and sqlite are not existent.
> Mentioning the t.connect work around and internal checks are certainly
helpful, but does not solve the underlying problem. Mapsets must be self-
contained.
Having the opportunity to set the temporal database mapset specific using
t.connect is not a work around, its a design decision. Well, we can remove
sqlite support to force the use of PostgreSQL as temporal database backend
to avoid the sqlite dilemma. Using PostgreSQL will avoid writing to any
mapset directory.
> One way is to have it fail-over into a sqlite db in the current mapset
dir tree. But really that needs to be the default, and so we need a way
for the various mapsets made accessible by g.access to connect, share, and
mix their sqlite dbs in memory, without blocking of two parallel grass
sessions running in the same common location at the same time.
Please can you point me to documentation howto share and mix sqlite dbs in
memory ... and also for other SQL DBMS?
>
> > The reason is that sqlite does not support the merging of different
database
> > files at runtime.
>
> Then we'll have to figure out some other way.. there must be a solution,
even if it is working with the python sqlite people to make their code
work the way we need it to, which would have the secondary effect of
helping many other projects too.
>
> Or maybe we can figure out some clever work around on our own- perhaps a
module to (re)scan other available mapsets' temporal sqlite dbs and write
out a local summary into $MAPSET/.tmp/, even as a flat text file if need
be?
The design decision to use a single database is indeed questionable. But
it is not limited to sqlite. The temporal framework was designed to
support different database backends. Hence the solution to support mapset
specific and central temporal databases must work with sqlite, PostgreSQL
and possible other database backends. I am thinking since the beginning of
the temporal framework design how to to support mapset specific databases
and central databases all together, but i don't come to a good solution.
Using several independent temporal databases (mapset specific or ...) will
reduce the SQL capabilities that can be used in the temporal framework
(IMHO the most important feature of SQL databases). SQL queries that make
use of where, group, having and order clauses will most of the time not
work across mapset specific independent temporal databases. Such
functionality must then be implemented in the temporal framework itself,
which requires the parsing and analysis of SQL strings ... which are
unfortunately SQL backend specific. This is a lot of work. Hence, most SQL
queries using where, group, having and order keywords can not be used to
select time stamped map layer or space time datasets from different
mapsets (Affected module is t.list and maybe other).
However, all the fancy SQL features can be used to select map layers from
space time datasets, since space time datasets are mapset specific. Hence,
the temporal framework can be modified to use mapset specific database
connections to process space time datasets. This will require the
modification of all database queries in the framework to specify the
mapset that should be used for the database connection. A central database
can be supported by using the same connection for different mapsets. This
is a huge effort. Probably all temporal modules must be modified as well.
So, what would be the best solution?
* Using a central database management system with server based DBMS and
abandon sqlite?
* Removing the SQL capabilities for cross mapset map layer and STDS
selection to support mapset specific temporal databases?
* Living with this design flaw, using t.connect to specify a central
temporal database that can be accessed by other mapsets if PERMANENT is
not the best choice?
If you think that the current temporal framework design is blocking the
release of GRASS7, then we should remove the temporal framework and all
temporal modules from the release version, developing it only in trunk,
marking it as highly experimental. I am fine with that. Actually, i would
to suggest this, since the temporal framework is still in development.
Several module manual pages are still missing and the design is obviously
not finished yet.
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2258#comment:11>
GRASS GIS <http://grass.osgeo.org>