Moritz wrote:
I think that with the move in 6.4 to SQLite as default db
backend,
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.
Hamish
Hi,
2009/5/7 Hamish <hamish_b@yahoo.com>:
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.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
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 <glynn@gclements.plus.com>
Hi,
2009/5/7 Glynn Clements <glynn@gclements.plus.com>:
[...]
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.
Right.
M.
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
On Thu, May 7, 2009 at 1:45 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2009/5/7 Hamish <hamish_b@yahoo.com>:
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.
Don't remember - is there a ticket?
Markus