On 05/03/09 10:43, Markus Neteler wrote:
Coming back to an old thread:
(SQLite as default DBMS driver)
On Mon, Jan 14, 2008 at 12:55 AM, Glynn Clements
<gl...@gclements.plus.com> wrote:
Hamish wrote:
Are there any instances where the dbf driver can do some
functionality that the sqlite driver cannot? I use the sqlite driver
all the time for my work with no problems.
DBF works "out of the box" on all platforms and is as well tested and
implimented as these things get. Its problems are well known.
AFAIU SQLite (by default) stores the DBs for all vector maps in a
single file per mapset. This makes it hard to share individual vector
maps and may have LFS issues when your data + mapset gets to be huge.
(??)
I doubt that LFS will be an issue in practice; I doubt that you'll
find an SQLite without LFS on any platform which supports it (i.e.
everything except for ancient Unices).
It probably wouldn't be hard to modify the SQLite DBMI driver to allow
one file per map (like for DBF), but then you lose the ability to
perform joins (OTOH, if you're using DBF, you never had this ability
in the first place).
Personally, I feel that the DBF driver is sufficiently "sub par"
compared to any other DBMS that I wouldn't consider "won't work with
the DBF driver" to be a valid design consideration in GRASS.
Developers should feel free to use e.g. arithmetic operators and joins
in SQL queries, rather than being constrained by the rather limited
capabilities of the DBF driver.
Suggestion:
make SQLite as default DBMS driver in devel_branch6 (alias GRASS 6.5).
Since today, in 2009, the driver has received a lot of testing, is definitely
superiour to DBF (where we regularly get complaints).
+1
If allowing one file per map isn't too hard to implement as optional feature
it might be a (last) requirement to make it the default driver.
I think that for the same arguments as those brought forward by Glynn
above, we should make single file db the default. Anyone who really
needs it can easily create a per-vector db with v.db.connect.
Concerning the need to be able to easily backup/share, I think we
definitely need some module which isolates and exports a series of
chosen maps in a new temporary mapset with a local sqlite db file,
copies the chosen maps into this temp mapset and then creates a tarball
(or zip or whatever) with the basic LOCATION info (i.e. a PERMANENT
mapset with PROJ and WIND files) and the temp mapset. Shouldn't be too
hard to wip up, or ?
Moritz
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
