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). 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. What are the opinions? Markus _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev