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 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? Do you plan to store tables linked to additional layers in the same SQLite file as the vector map? 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? Just some thoughts ... Cheers Stefan From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Sören Gebbert Sent: 9. september 2016 23:07 To: GRASS developers list <grass-dev@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
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
