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

[Moritz Lennert]

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

+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