Hi devs,
I would like to ask you for your opinion... to use sqlite as default
db driver for grass64 (instead of dbf). What do you think?
Martin
--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
I would like to ask you for your opinion... to use sqlite as default
db driver for grass64 (instead of dbf). What do you think?
Martin
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.
~ Eric.
On Jan 11, 2008 2:26 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi devs,
I would like to ask you for your opinion... to use sqlite as default
db driver for grass64 (instead of dbf). What do you think?
Yes, that would be very good. AFAIK:
Functionality
- it does all the DBF driver does and way more
Portability
- works on all common operating systems
Installation efforts:
- despite the base installation, zero maintenance
Markus
I would like to ask you for your opinion... to use sqlite as default
db driver for grass64 (instead of dbf). What do you think?
Yes, that would be very good. AFAIK:
Functionality
- it does all the DBF driver does and way morePortability
- works on all common operating systemsInstallation efforts:
- despite the base installation, zero maintenanceMarkus
Also,
License: Public Domain
~ Eric.
Martin Landa wrote:
Hi devs,
I would like to ask you for your opinion... to use sqlite as default
db driver for grass64 (instead of dbf). What do you think?
For consistency I would suggest changing it for GRASS 7 but not GRASS
6.x.
Hamish
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
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.
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.
(??)
There is no question that SQLite has decades better functionality.
2c more,
Hamish
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Hamish,
On 1/11/08, Hamish <hamish_b@yahoo.com> wrote:
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.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.
... but not solved.
Also for me table joins, math SQL is essential.
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 am sure that we could rather easily change this to map-wise
storage or make it optional.
Markus
There is no question that SQLite has decades better functionality.
2c more,
Hamish
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.
--
Glynn Clements <glynn@gclements.plus.com>
On Jan 13, 2008, at 5:55 PM, Glynn Clements wrote:
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.
(??)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).
I also like the idea of one db file per map. But I didn't know about the join problem (I can see joins being useful). Perhaps a db extract command can be added for when one wants to isolate a map's files?
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
"We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty."
"Don't you even hate 'em?"
"What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the ____ it wouldn't kill one ___ nor shorten the war one day."
<Ha, ha> "And it might give 'em all stomach ulcers."
- Tarzan, on war
Glynn Clements <glynn@gclements.plus.com> writes:
>> 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).
A shot in the air:
$ cat create-table.sql
CREATE TABLE foo
AS SELECT 1 AS item, 'Foo'
UNION SELECT 2 AS item, 'Bar'
UNION SELECT 3 AS item, 'Baz';
$ cat create-and-join.sql
CREATE TABLE bar
AS SELECT 1 AS item, 'Description #1'
UNION SELECT 2 AS item, 'Description #2'
UNION SELECT 3 AS item, 'Description #3';
ATTACH DATABASE 'foo.db' AS "foo-db";
SELECT * FROM "foo-db".foo INNER JOIN bar USING (item);
$ sqlite foo.db < create-table.sql
$ sqlite bar.db < create-and-join.sql
1|Foo|Description #1
2|Bar|Description #2
3|Baz|Description #3
$
[...]
On 14/01/08 00:55, Glynn Clements wrote:
It probably wouldn't be hard to modify the SQLite DBMI driver to allow
one file per map
Why would you have to modify the driver ? You can already do so by setting v.db.connect to a seperate file. So, it's more a question of what should be done by default than allowing it, or do I misunderstand something ?
Moritz
Moritz Lennert wrote:
> It probably wouldn't be hard to modify the SQLite DBMI driver to allow
> one file per mapWhy would you have to modify the driver ? You can already do so by
setting v.db.connect to a seperate file. So, it's more a question of
what should be done by default than allowing it, or do I misunderstand
something ?
If you normally use one file per map, having to keep running
v.db.connect would be a nuisance. A modified version would work the
way that the DBF driver does, i.e. you "connect" to a directory which
would have an SQLite file for each map.
--
Glynn Clements <glynn@gclements.plus.com>
> 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
Good point. Probably there should be some GRASS module to help moving
around raster/vector data?
I.e. g.export rast/vect=mymap out=myfile.tgz and g.import in=myfile.tgz
Required features:
* needs to preserve vector topology(!);
* preserves history, metadata etc.;
* simple source/target projection check.
IMHO it will be more easy to create such data exchange modules than
implement all SQL RDBMS features in GRASS for managing data in DBF's
or other poor backends.
Oh, yeah - g.copy is not an option - it still segfaults on my Gentoo
~x86 machine (6.3.0RC4). I can only copy raster maps with r.mapcalc 
Maris.
2008/1/15, Hamish <hamish_b@yahoo.com>:
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