[GRASS-dev] Separate sqlite database files for vector maps
Sören Gebbert
soerengebbert at googlemail.com
Sat Sep 10 14:39:32 PDT 2016
Hi,
i found a simple solution with the help of Markus Metz:
db.connect driver=sqlite database='$GISDBASE/$LOCATION_
NAME/$MAPSET/vector/$MAP/sqlite.db'
This will set the database connection for all vector maps in a mapset,
hence it should be run directly after mapset creation.
2016-09-09 23:40 GMT+02:00 Blumentrath, Stefan <Stefan.Blumentrath at nina.no>:
> Hei Sören,
>
>
>
> I ran into this recently too, with lots of “Busy SQLite” warnings, when I
> tried to modify two or more vector maps in parallel.
>
> So the work you are planning to do would be very much appreciated.
>
>
>
> However, in order to not break existing modules like v.db.join, queries
> across SQLite DBs would have to be supported.
>
> Here the “attach” keyword might be a starting point for required additions
> to e.g. v.db.join: http://sqlite.org/lang_attach.html
>
The simple solution that works for me will not work with modules that
require a single database to store all vector tables. Hence, all the
modules that do not work with dbf databases may also not work with vector
map specific sqlite databases.
>
>
> It is probably also necessary to think about how (or more precise where)
> tables are supposed to be handled which are not linked to a vector map...
> Will all non-map tables be saved in their own SQLite DB file?
>
>
I have no clue since i don't have these requirements.
> Do you plan to store tables linked to additional layers in the same SQLite
> file as the vector map?
>
Nope.
>
>
> How would modules like db.tables or db.copy behave? What happens if you
> connect the attribute table of map a (or just table a) to map b?
>
I see no problem with db.tables and db.copy since all db.* commands have
database options to specify the path to the required sqlite database.
Connecting a table from map a to map b will not work with the simple
solution.
IMHO the simple db.connect solution should provide all the functionality
that i need at the moment, which are parallel vector map processing and
mapset merging.
Best regards
Soeren
>
>
> Just some thoughts ...
>
>
>
> Cheers
>
> Stefan
>
>
>
>
>
> *From:* grass-dev [mailto:grass-dev-bounces at lists.osgeo.org] *On Behalf
> Of *Sören Gebbert
> *Sent:* 9. september 2016 23:07
> *To:* GRASS developers list <grass-dev at lists.osgeo.org>
> *Subject:* [GRASS-dev] Separate sqlite database files for vector maps
>
>
>
> Dear devs,
>
> i would like to implement sqlite database support as separated file for
> each vector map. Similar to the dbf approach but with sqlite. Other
> databases are no option in my case.
>
> The reasons for this approach are the following:
>
>
>
> * The temporal vector algebra would hugely benefit from separated sqlite
> vector map files, since it can compute in parallel, no race condition or
> serial processing of database requests is required
>
> * Vector maps can easily be moved between locations with full database
> content, no data loss. Simply the vector map directory must be archived
>
> * Merging of mapsets is much easier, since the vector map sqlite databases
> don't need to be merged, only copied
>
>
>
> This approach would be implemented in addition to all other existing
> approaches.
>
>
>
> However, i don't know were to start with this, any hints or suggestions?
>
>
>
> Best regards
>
> Soeren
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20160910/3000c655/attachment-0001.html>
More information about the grass-dev
mailing list