QGIS/python/core/auto_generated
Alessandro Pasotti 7fa6f38689 Memory provider: roll back on errors
Long story short: calling provider's addFeatures
is implemented for some providers in a way that
will roll back all changes on errors, leaving
the backend storage unchanged.

Adding a QgsFeatureSink flag to control this
behavior allows certain providers to support
partial feature addition.

The issue comes from QgsVectorDataProvider::commitChanges
that is documented to leave the provider unchanged (roll
back) on any error, giving the client code the possibility
to fix errors (in the editing buffer) and re-commit.

Without a full rollback implementation in the memory
provider and after the type check introduction in this
PR we ended up with situations like this:

vl = ... an empty memory layer
self.assertTrue(vl.addFeatures([valid, invalid]))
self.assertFalse(vl.commitChanges())
self.assertEqual(vl.featureCount(), 1)  <--- fails!
We actually had 3 features from vl.getFeatures():
[valid, invalid, valid] (the first from the provider
the second and third from the editing buffer).

On the other hand, QgsFeatureSink would probably assume
that addFeatures will allow partial additions.

BTW: This is for sure the longest commit message I've ever
     written.
2020-06-20 04:30:18 +10:00
..
2020-03-18 10:04:52 +10:00
2020-06-20 04:28:18 +10:00
2020-06-15 08:54:04 +02:00
2020-04-30 06:52:22 +02:00
2020-06-19 08:47:23 +10:00
2020-06-11 13:29:59 +10:00
2019-11-20 08:12:39 -05:00
2019-11-02 15:01:59 +01:00
2020-06-19 08:47:23 +10:00
2020-06-11 13:29:59 +10:00
2020-06-11 13:29:59 +10:00
Dox
2019-11-02 15:12:23 +01:00
2020-06-19 08:47:23 +10:00
2019-10-26 06:46:09 +10:00
2020-06-19 08:47:23 +10:00
2020-06-19 08:47:23 +10:00
2020-06-11 13:29:59 +10:00
2020-01-14 19:08:20 +13:00
2020-05-18 14:34:45 +07:00
2020-06-19 08:47:23 +10:00
2020-06-19 08:47:23 +10:00
2020-06-11 13:29:59 +10:00
2020-06-19 08:47:23 +10:00