[Qgis-developer] Vector buffer commitChanges (was Interaction between QGis and ArcGis)

[Radim Blazek]

On Fri, Apr 26, 2013 at 10:09 AM, Martin Dobias <wonder.sk at gmail.com> wrote:
> On Wed, Apr 24, 2013 at 12:20 PM, Radim Blazek <radim.blazek at gmail.com> wrote:
>>>
>>> Maybe better, but we are already using startEditing() and
>>> commitChanges() in vector layer so I would prefer to use the same.
>>
>> I added to QgsVectorDataProvider:
>>
>> virtual bool startEditing();
>> virtual bool rollBack();
>> virtual bool commitChanges();
>> virtual bool isEdited();
>> signals:
>>   void editingStarted();
>>   void editingStopped();
>>
>> As I said, to keep names consistent with vector layer. Currently not
>> implemented nor used. It would be useful to have it implemented for
>> 2.0 at least in ogr provider to resolve #6448 at least for reading.
>
> If the startEditing() and commitChanges() are going to be called
> within QgsVectorLayer::commitChanges(), then I find the names
> confusing and begin/commit/rollback-Transaction() would be IMHO
> better. They do different things, so they should have different names.
> And while using startEditing() and commitChanges() is necessary for
> editing within QgsVectorLayer, calling those functions in
> QgsVectorDataProvider should be optional (edit functions should
> automatically open a transaction and then close it afterwards).

The original motivation for that methods was to reopen files in r+
mode, not to start transaction in DB provider. It is not possible to
reopen files in each provider edit method and startEditing() would
have to be obligatory. However, as I am thinking about it more, it
seems that reopening files could cause more troubles than keeping them
always in r+ mode. Until now, it does not appear to be a problem to
open files in r+ mode, apart the slowness on Windows which is only a
side effect. The suggested read only mode + VSI cache was only a
workaround, not resolution of the problem which is in OGR.

I'll probably remove those new methods. If we find it necessary to use
read only mode for files, we can reopen them in r+ first time a
provider edit method is called. That should isolate the problem in OGR
provider. Begin/commit/rollback-Transaction() may be added later, it
should not break the API.

>> Currently all editing methods in postgres provider do changes in
>> transactions. If we implement QgsPostgresProvider::startEditing() it
>> should start new transaction and all changes should be done within
>> that transaction. Are there any potential problems?
>
> I do not see any right now.
>
>> Should the startEditing() / commitChanges() close all iterators?
>
> Good question: this needs more thoughts. Closing them makes sense
> because with some providers the iterators would not return correct
> results. However that would mean that some code will stop working.

The same question probably applies to all provider edit methods.

Radim

> Martin