sqlite and grass65: was Re: [GRASS-dev] sqlite and grass64
neteler at osgeo.org
Thu Mar 5 04:43:20 EST 2009
Coming back to an old thread:
(SQLite as default DBMS driver)
On Mon, Jan 14, 2008 at 12:55 AM, Glynn Clements
<glynn at 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.
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?
More information about the grass-dev