sqlite and grass65: was Re: [GRASS-dev] sqlite and grass64

[Markus Neteler]

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.
>

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