Martin Landa wrote: > >> I think that with the move in 6.4 to SQLite as default db > >> backend, > > Probably we could move to SQLite in GRASS 6.5. Note there are still > remaining bugs, e.g. v.dissolve doesn't work on string column. > > > DBF remains the default in 6.x, see include/dbmi.h "DB_DEFAULT_DRIVER". > > It is only changed to sqlite in grass7. > > > > todo: for sqlite decide if we want per-map DB files like with DBF or > > single DB file per mapset. I'd vote for per-map files so it takes longer > > to reach any 32bit filesystem filesize limits, limits the effect of DB > > corruption, and makes it easier to move maps around, but then I don't do > > any fancy joins etc that might take advantage of a single file per mapset > > approach. > > I would vote for both approaches. User can decide what he prefers via > environmental variable, e.g. GRASS_SQLITE_PER_MAPSET.
There's no reason to use an environment variable. This should be dealt with by the database setting (VAR or dblink). If it refers to a directory, use a <mapname>.db file for each map. Otherwise treat it is the name of an SQLite database file to use for all maps. -- Glynn Clements <gl...@gclements.plus.com> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev