[GRASS-dev] sqlite and grass64

[Hamish]

> > Eric:
> > > 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.
Hamish:
> > DBF works "out of the box" on all platforms and is as well tested
> > and implemented as these things get. Its problems are well known.
Markus:
> ... but not solved.
> Also for me table joins, math SQL is essential.

I don't use DBs much, so in general I am happy to stand back and let
those devels that do spend their time working with DB/SQL decide this.
I just like to play conservative with the release branches, and 6.4
isn't far off from branching time.

For sure 6.2.x should not change away from DBF as default and I would
worry about making such an important change for 6.3.0 with so little
testing time remaining before release.

If it is decided to use SQLite as default for the 6.4 series, for
maximum testing time I would suggest changing it ASAP in SVN trunk.


HB:
> > 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.
> > (??)
MN:
> I am sure that we could rather easily change this to map-wise
> storage or make it optional.

I have no idea how important SQL joins + single DB files are.

If is desired to split into separate files, they could live in
vector/$MAPNAME/sqlite_1.db files or whatever instead of $MAPSET/dbf/
style dir. But again I have no idea if that causes problems for joins.

At least there has to be a way of extracting a single vector map
without resorting to making a new mapset and 'g.copy vect=' just the
one map then tarballing the single-map mapset.


Hamish



      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs