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

Reply via email to