[prev in list] [next in list] [prev in thread] [next in thread] 

List:       grass-user
Subject:    [GRASS-user] syncing two locations || default DB -> SQLite
From:       hamish_b () yahoo ! com (Hamish)
Date:       2008-05-28 9:34:43
Message-ID: 609626.57601.qm () web45812 ! mail ! sp1 ! yahoo ! com
[Download RAW message or body]

> > > 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




      


[prev in list] [next in list] [prev in thread] [next in thread]