On Mon, Nov 20, 2017 at 3:51 PM, Matthias Kuhn <[email protected]> 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 [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > > > _______________________________________________ > QGIS-Developer mailing list > [email protected] > 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
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
