[QGIS-Developer] Editing buffer and commitChanges order

[Alessandro Pasotti]

On Mon, Nov 20, 2017 at 3:51 PM, Matthias Kuhn <matthias at opengis.ch> wrote:

> Hi Alessandro,
>
> This problem also applies to editing multiple layers in parallel
> (especially with foreign keys), that was one of the drivers to introduce
> transaction editing.
>
> For individual layers, I think we can keep track of all the changes in the
> local edit buffer. For issue 16935, I think the order wouldn't actually
> change much, it would still fail, just in a different order?
>

Yes, but without data corruption. That is what we need to fix with higher
priority, if the operation fails without crippling the data I think it
would be acceptable, but if it fails with data loss that is not acceptable.


> One thing there is, the commands could be sent in a single transaction
> (which doesn't necessarily need to be managed by QgsTransaction).
>

I don't understand this part: QgsTransaction looks like the right class to
handle transactions, I think it should be used to wrap the whole
commitChanges for providers that support the transactions.

On the other hand, I think splitFeature should be using
> QgsVectorLayer.createFeature() which should take care of unique constraints
> detected on the provider. If I'm not mistaken, this works fine on postgres,
> possibly there's an issue with unique constraint detection in sqlite based
> providers?
>

It is using that class ...

Thanks! I'll look into that method, it looks like a good lead.



Cheers
>
> Matthias
>
> On 11/20/2017 01:02 PM, Alessandro Pasotti wrote:
>
> Hi,
>
> I'm facing a bug [1] that led me to a potential issue in the editing
> buffer implementation: when commitChanges is called, different operations
> (change geometry, change attrs, add features, delete features ...) are
> grouped and executed in a fixed order.
>
> So, if I wanted for example insert a feature and (after the insert has
> been successful)
> change the geometry of another feature I cannot do that because all
> geometry editing operations are grouped and executed before all the insert
> feature operations are executed [2]
>
> This issue can lead to data loss in several scenarios, one is the bug I'm
> working on here but there are more: for example when you want to merge
> features you cannot delete features after you have successfully created the
> merged one, just because all delete operations are performed before the
> insert ones.
>
> I guess that by grouping related commands together we probably wanted to
> make it easier to optimize the operations in the back-end.
>
> Wrapping the commitChanges into transactions would help with DB-like
> backends that support it (I think that the implementation is not yet
> completed), but I'm still convinced that the order of edit commands within
> an editing buffer should be respected (that does not mean that certain
> commands cannot be grouped if the programmer choose to do so).
>
> I'd like to hear your opinion about the possible solutions to this problem.
>
>
> [1] https://issues.qgis.org/issues/16935
> [2] https://github.com/qgis/QGIS/blob/master/src/core/
> qgsvectorlayereditbuffer.cpp#L300
>
>
> --
> Alessandro Pasotti
> w3:   www.itopen.it
>
>
> _______________________________________________
> QGIS-Developer mailing listQGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>



-- 
Alessandro Pasotti
w3:   www.itopen.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20171120/4da969e3/attachment-0001.html>