Hi Even, On 03/22/2016 10:31 AM, Even Rouault wrote: > Hi, > > I'm considering addressing an issue that mainly involves concurrent use of a > MapInfo TAB dataset by QGIS and MapInfo, as described in > https://hub.qgis.org/issues/14378, although the planned fix would be a bit > more > general. > > The problem is that when QGIS opens a OGR datasource it tries to open it with > the update mode of the OGROpen() API, which in turn opens the underlying > file(s) with a mode (dwDesiredAccess = GENERIC_READ | GENERIC_WRITE and > dwShareMode = > FILE_SHARE_READ | FILE_SHARE_WRITE with the Windows CreateFile API()) that is > incompatible with the mode with which MapInfo tries to open files in > read-only > (dwDesiredAccess = GENERIC_READ and dwShareMode = > FILE_SHARE_READ). Hence MapInfo cannot open a MapInfo dataset already opened > by QGIS in update mode. > > The solution I'm considering would be to modify the QGIS OGR provider to : > - try to open the dataset in update mode as currently, but if it is > successful, go back to re-opening it in read-only mode. (we need to try to > open in update mode so as to have appropriate capabilities) > - for operations like addFeatures(), addAttributes(), etc ... that need > update > permissions, check the current open mode, and if not update mode already, re- > open the OGR datasource in update mode > - go back to read-only mode when the user exists the edition mode (this would > need a new method in the QgsVectorDataProvider API to warn about that, since > the provider has currently no way of knowing that)
I think the postgres provider already has a similar concept for connection pooling. For read-only operations, a shared r/o connection from the connection pool is obtained. When writing is required, a new "transaction" connection with write capabilities is opened for the duration of the r/w session. Maybe this concept can be mirrored by the ogr provider? > > There would be of course a cost to pay due to this open / close operations, > so > I think I would limit it to shapefiles and mapinfo for now, since the opening > of such datasets doesn't involve a lot of I/O ( the most costly is for > shapefiles where the whole .shx is ingested into memory ). > > Another related fix would be to implement reloadData() in the OGR provider so > that the user can resynchronize its QGIS session for a dataset modified by > another software. Concerning the reloadData() method, there is already a forceReload() method which reloads a changed dataset (on request) in QGIS. Is your plan to implement a "change detection" and trigger this action automatically? It's good to see somebody as experienced as you with ogr taking care of these issues. Matthias > > Thoughts ? > > Even > -- Matthias Kuhn OPENGIS.ch - https://www.opengis.ch Spatial • (Q)GIS • PostGIS • Open Source
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Qgis-developer mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
