[GRASS-user] syncing two locations || default DB -> SQLite
hamish_b at yahoo.com
Wed May 28 09:34:41 EDT 2008
> >> 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..
> 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; ...
More information about the grass-user