On 10.07.2017 13:58, Even Rouault wrote:
> I did some playing around and came up with some FeatureId mapping code
> which is pretty space efficient (basically requiring just
> 3*nDeletedFeatures entries), see below.
>
> The code however assumes that the gaps in the fid-sequence are filled by
> decreasing the fids after the gap, which may be pretty specific to the
> OGR/Shapefile behaviour.
This should clearly be restricted to Shapefiles. Other drivers don't
have this compaction logic and will let happily holes in the feature ids.
> Hence in my view such code should really belong
> into the OGR provider (or perhaps even ogr itself) and not in the
> plugin. Thoughts?
Regarding putting that in OGR itself, there's no such API for that
right now, and I'm not completely clear of the value to add one
(specific use case, for a single driver)
Perhaps the QGIS OGR provider would be a better place for now.
So that kinda works, but repacking still causes dreadful performance
(say after fixing a couple of hundred "minimal area" errors, which
results in the small features getting deleted, the shapefile is repacked
after every delete).
So I'd really need a way to freeze repacking, even just for the timespan
the plugin is busy fixing the errors. Unless there are some better
ideas, I'll look at adding corresponding methods. A cool name would be
beginTransaction/endTransaction which is kinda generic and could make
sense for other providers as well, but unfortunately it collides with
the existing transaction logic (QgsTransaction) which is about
multi-layer transaction groups...
_______________________________________________
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
