[GRASS-dev] [GRASS GIS] #2258: t.create creates DB always in the PERMANENT

[GRASS GIS]

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