[GRASS-user] syncing two locations || default DB -> SQLite

Hamish 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 mailing list