> >> One problem I foresee is with vectors using a single
> >> sqlite.db file,
> >
> > That's true. You cannot write simultaneously to
> > the same sqlite.db file.
...
> > But just use different names, so multiple sqlite.db files?
IIRC you can make SQLite create per-vector map DBs by setting the
[v.]db.connect database= string the appropriate way. I am not totally certain
about that. If not it would be nice to have. By using a single file for the
entire mapset's DB needs you much more quickly reach >2gb file sizes, make it
less flexible for backups, have longer seek times, more chance for a single bit
of data corruption to cascade etc.
I don't know which way is better, for now I hope we can have both ways and race
them against each other to see which one wins.
I'll even press the issue. I just made SQLite the default DB in grass7/trunk.
(using a single sqlite.db file per mapset)
We'll see what happens..
Mark:
> I completely agree to use your approach, with the shared
> location with multiple mapsets. Using something like Unison
> sync's the locations well, but has problems with single file
> reconciliation such as an sqlite.db file for all the vector
> attributes. Now I have some vector files that dont have attributes.
> :-( It seems to work fine for rasters, but cant say for
> absolute. I would stick with your approach, or use the linux
> clustering approach like you mentioned.
other ideas: NFS mount common dir; openMosix's distributed filesystem
(seemingly built for this exact task); common Samba share; ...
Hamish
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
