[Qgis-developer] Proposed plan to fix issue with concurrent opening of OGR datasources (aka QGIS and MapInfo)

[Even Rouault]

Le mardi 22 mars 2016 13:53:10, Matthias Kuhn a écrit :
> On 03/22/2016 01:44 PM, Hugo Mercier wrote:
> > On 22/03/2016 12:11, Even Rouault wrote:
> >>>> True.
> >>>> But you can also directly access the provider update methods without
> >>>> edit buffers and without startEditing / commitChanges.
> >>> 
> >>> Good point. I didn't think at that use case of direct access to the
> >>> provider API.
> >>> 
> >>>> ... but after all ... if I understood correctly your intents, for
> >>>> existing codes that use this direct provider access, update functions
> >>>> will reopen the source in write mode and they will always stay in that
> >>>> mode because the endEdit() method will never be called ?
> >>> 
> >>> Yes.
> >>> 
> >>> One possibility would be also to go back to read-only mode with a
> >>> timer. For a write operation, outside of beginEdit() / endEdit(), that
> >>> lead to re-opening in update-mode, after X seconds without write
> >>> activity, the dataset would be re-opened in update mode.
> >> 
> >> correction: "...would be re-opened in *read-only* mode"
> > 
> > I am not sure to like this timeout ... I prefer when the state of
> > objects does not silently change in background :)
> > Doing nothing would be ok: existing (plugin) codes would lock under
> > windows, which is already the case, and would have the opportunity to be
> > safer by calling endEdit().
> 
> What about adding the re-open file code at the beginning and end of the
> dataprovider functions (QgsOgrProvider::addFeatures etc.)?

That could be done for sure, but wouldn't there be performance issues if the 
editing API of the provider are called multiple times in a sequence ? Although 
the methods that change the features take multiple features at once, so the 
effect of re-opening at the beginning and end of the provider functions might 
be limited.

> 
> If we're afraid that there is too little control this way, we could
> still add a controlled "update state" to the provider and in case this
> is already set, the re-opening will be skipped.

That's a bit equivalent to the beginEdit() / endEdit().

We could have as valid scenarios :

1. beginEdit() ( or setUpdateMode(true) )
2. addFeatures() 
3. endEdit() ( or setUpdateMode(false) )

or

1. addFeatures() --> re-open implicitly to update mode if not already done, do 
the operation and let it in update mode

or

1. addFeatures() --> re-open implicitly to update mode if not already done, do 
the operation and let it in update mode
2. endEdit()  ( or setUpdateMode(false) ) --> go back to read-only mode



-- 
Spatialys - Geospatial professional services
http://www.spatialys.com